Quand on pense agilité, d’autant plus lorsque nous utilisons des Frameworks comme Scrum, parmi les premiers outils que nous utilisons, on trouve régulièrement l’usage des story points pour estimer la complexité des charges de travail.
Cependant, de part mes expériences, je me suis rendu compte que l’usage des points de complexité pour estimer une charge était généralement mal compris.
Doit-on estimer juste le coût de développement ? Doit-on y inclure les tests ? Est-ce que 1 point doit être égal à 1 jour ? Ce sont quelques questions que j’ai pu entendre.
De plus, je me suis rendu compte que les équipes perdaient assez rapidement en qualité d’échanges et tombaient dans un consensus en chiffrant une complexité moyenne par habitude plus que par débat.
Pour aider les équipes au chiffrage, il existe plusieurs outils comme, par exemple, Wall Of Référence, Bucket système ou encore Quadrant d’estimation…
Par cet article je vais vous présenter une manière différente d’aborder les estimations et de conserver un niveau intéressant de débat. Je propose d’utiliser un outil : le CURSE.
Je propose d’utiliser l’outil CURSE que j’ai découvert en lisant l’article de Bill DeVoe (https://www.artemisagile.com/curse-your-way-to-better-scrum-story-points/).
CURSE ?
CURSE est un acronyme qui désigne un ensemble d’angles d’observation du besoin afin de favoriser la discussion autour de son coût. Pour imager cette pratique, je me sers souvent d’un parallèle culinaire afin d’aider les équipes à en comprendre le fonctionnement…
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é !
