Comment empêcher l'inflation des estimations
Auteur : Mike Cohn
Source : How to Prevent Estimate Inflation
Date : 03/05/2016
Traducteur : Fabrice Aimetti
Date : 19/07/2017
Traduction :
J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.
Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.
La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.
L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.
Pourquoi l'inflation des estimations apparaît-elle ?
Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.
La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.
Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le Planning Poker (fr)). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.
A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.
Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.
Et donc cette story a été estimée à cinq.
Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.
Et c'est comme cela que l'inflation des estimations survient.
Comment empêcher l'inflation des estimations ?
J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre Agile Estimating and Planning, j'y fais référence en appelant cela la triangulation, empruntant ainsi un vieux terme nautique pour localiser un navire.
Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander "Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?".
Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :
Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.
Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.
Idéalement, nous aimerions comparer chaque estimation à toutes les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.
Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :
Chaque story, de A à F, a été comparée à deux ou trois autres stories.
Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.
La triangulation arrête l'inflation des estimations
La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.
Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.
Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.
Il existe encore un meilleur moyen d'empêcher l'inflation des estimations
Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous le faire si cela vous intéresse d'en apprendre plus.
Qu'en pensez-vous ?
Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.
