C pour la complexité (complexity) : la complexité représente la difficulté globale de la réalisation de notre besoin.

Lorsque les éditeurs de livre de cuisine écrivent une recette, ils estiment une complexité. Celle-ci ne prend pas en compte l’expertise du cuisinier. Pour les estimations agiles, il devrait en être pareil. Considérer le « qui » dans la complexité reviendrait à rajouter une notion de temps selon les connaissances de la personne. Or, en agilité, le temps est considéré par la vélocité et non la complexité.

espace

espace

U pour l’incertitude (Uncertainty) : l’incertitude représente les données non connues liées à un besoin.

Dans l’exemple suivant, on se rend bien compte que l’incertitude est grande, car il manque beaucoup de données importantes.

Dans le cadre de l’incertitude, on va estimer la non certitude sur le besoin, la capacité à faire, les impacts non maitrisés, les dépendances…

espace

espace

R pour le risque (Risk) : pour le risque, on vérifie à quel point le besoin emmène du risque et peut être dangereux pour l’ensemble du système.

On se rend bien compte que préparer un repas pour un hôtel 3 étoiles n’est pas le même risque que de préparer un repas pour soi à la maison.

espace

espace

S pour la portée (Scope) : la portée représente l’ampleur du travail sur le système et les impacts liés.

Dans ce cas, la portée est connue : 4 personnes. Si l’on doit reproduire la même recette pour 100 personnes, on accepte que cela représente un scope plus important donc un coût plus important.

espace

espace

E pour l’effort (Effort) : l’effort représente la somme de travail à accomplir pour réaliser le besoin.

Pour le calcul de l’effort, il faut bien entendu discuter des différentes étapes pour réaliser le besoin. Attention toutefois au niveau de détails. Trop de détails pourrait être contre productif car demanderait trop d’efforts pour les obtenir.

espace

espace

Dans la pratique

Pour utiliser cet outil, je vous recommande de le visualiser sous forme de RADAR.

Pour cela, vous pouvez vous servir de l’outil numérique développé par Nicolas Poncet et Pascal Dehaies ici.

Vous pourrez utiliser cet outil lors de différentes phases de découverte de votre besoin. Par exemple, pour la découverte d’épic ou de features en le couplant avec des estimations en taille de t-shirt, ou encore lors de la découverte des user story en le couplant avec des estimations en story point. Pour ce deuxième exemple, il existe aussi une variante, le DUSTER qui sépare la complexité en deux : complexité de développement et complexité de test.

Bien entendu, le CURSE est un outil parfaitement modifiable : vous pouvez ajouter ou retirer des axes de réflexion afin de le rendre le plus adapté à votre contexte. Par contre, il ne s’appellera plus CURSE. Cependant, CURSE a le mérite de permettre à l’équipe de se questionner sur les axes principaux, liés au développement de nouvelles fonctionnalités.

Arriver à dissocier la notion de temps de la complexité n’est pas toujours facile pour les équipes. En utilisant CURSE, nous pouvons avoir une approche plus large et plus réaliste des défis qui nous attendent. La notion du temps est diffuse dans l’ensemble des axes, sans pour autant l’aborder directement. La notion directe et concrète du temps se retrouve alors portée par la notion faite pour cela : la vélocité !