Dans les méthodes agiles, les estimations se font de manière collective (l’ensemble de l’équipe intervient) et de manière relative (les fonctionnalités sont estimées les unes par rapport aux autres), et sont réalisée par ceux qui font réellement le travail.
Bien que le planning poker soit la méthode la plus utilisée, il en existe d’autres. Zoom sur les différentes méthodes d’estimation agile.
Et à ceux qui seraient tentés d’estimer en jours/homme en agile, je vous renvoie à cet article qui va vous expliquer pourquoi les estimations absolues en jours/homme sont vouées à l’échec.
Pour aller + loin : Dans cet article, je pars du principe que vous connaissez les concepts des story points. Si ce n’est pas le cas, je vous invite à lire mon guide sur le sujet.
9 méthodes d’estimation pour les user stories
1 ) Le planning poker
Le planning poker est certainement la méthode d’estimation agile la plus connue et la plus répandue.
Toute l’équipe est réunie pour « jouer » au planning poker, et se voit distribuer des cartes représentant les valeurs des points d’effort.
Chaque fonctionnalité ou user story est présentée à l’équipe et débattue, puis l’équipe passe au vote. Chaque participant tire une carte pour indiquer quelle est son estimation. Les cartes sont ensuite retournées de manière simultanée pour éviter que les votes des uns influencent les autres.
Si les estimations diffèrent, on demande à ceux ayant mis les notes les plus basses et les plus hautes ce qui les a décidé, puis on réalise un second tour de table afin de trouver un consensus sur les points d’efforts.
On procède ainsi jusqu’à épuisement des user story à estimer.
Pour aller + loin : Pour approfondir le concept du planning poker, vous pouvez consulter mon article sur le sujet.
2 ) Le bucket system
Le principe est le même que le planning poker, à la différence que l’on n’utilise pas des cartes mais des conteneurs (des seaux, d’où le nom).
Bien sûr, ces conteneurs peuvent être représentés par une colonne sur un tableau.
Voici comment se déroule un bucket system :
- On choisit aléatoirement une user story, et on la place dans le conteneur 8. Elle servira de fiche de référence pour les autres estimations.
- On choisit à nouveau aléatoirement une user story.
- Les participants discutent jusqu’à trouver un consensus sur l’effort à réaliser. Une fois que l’équipe est d’accord, on place la fiche dans le conteneur approprié.
- On répète l’étape 3 3 fois. Ces 3 fiches sur lesquelles l’équipe s’est mise d’accord vont servir de référence également pour le reste des estimations.
- On répartie alors l’ensemble des user stories de manière équitable entre tous les participants.
- Chacun peut ensuite placer ses fiches dans les conteneurs qu’il estime le plus approprié, sans demander l’avis aux autres.
- Vient alors la dernière phase, la phase d’épuration. Le positionnement de l’ensemble des fiches est évalué et si quelqu’un juge qu’une fiche n’est pas à sa place, on ouvre le débat jusqu’à trouver un consensus.
Ce qui est intéressant avec le bucket system, c’est qu’il s’agit d’une méthode d’estimation efficace, qui demande moins de temps que le planning poker tout en permettant d’estimer un grand nombre de fonctionnalités d’un coup.
3 ) La magic estimation
La magic estimation est une méthode qui se pose en remplacement du planning poker et qui permet d’obtenir de bonnes estimations en un temps record.
La durée d’une magic estimation est généralement de 30 à 60 minutes et est généralement utilisée pour estimer tout un product backlog, afin de créer la product roadmap.
Voici comment se déroule une séance de magic estimation :
- Étalez les cartes de planning poker sur le sol ou sur une surface plane.
- L’équipe sélectionne une user story qui servira comme point de référence et lui attribue une valeur de référence, par exemple 5.
- Les user stories sont réparties de manière équitable entre tous les participants. Chacun va placer les fiches en silence en lui attribuant le point d’effort qui lui convient le mieux.
- Si l’on n’est pas capable d’estimer l’effort nécessaire pour réaliser une fonctionnalité, on la place sur la carte « ? » (point d’interrogation). Ces cartes sont alors discutées avec le product owner afin de clarifier les attendus et ainsi permettre l’estimation.
- Les points d’effort du round 1 sont notés sur chaque fiche.
- On passe alors au round 2. Chaque participant analyse en silence le classement des user stories et s’il n’est pas d’accord avec le classement, il peut alors déplacer la user story. Une fiche ne peut cependant n’être déplacé qu’une seule fois par round.
- Notez les nouveaux points d’effort sur les fiches.
- Les user stories qui n’ont pas été déplacées sont considérées comme « Ok » et sont récupérées par le product owner.
- Celles qui ont été déplacées mais dont l’écart reste minime (2 à 3 points) sont également récupérées par le product owner.
- Faites un round 3, et répétez les étapes 6 à 9.
- Ouvrez les discussions concernant les fiches qui ont beaucoup été déplacées afin de trouver un consensus dans l’équipe.
Cette méthode d’estimation permet d’avoir un historique des différents points d’effort attribués. Ils peuvent être utilisés dans des scénarios « best case » et « worst case ».
4 ) L’extreme quotation
L’extreme quotation est une méthode qui se rapprocher de la magic estimation.
Voici son déroulement :
- Étalez les cartes de planning poker sur le sol ou sur une surface plane.
- Le product owner donne une vue d’ensemble des différentes fonctionnalités à estimer.
- Chaque participant prend une fiche à tour de rôle et la positionne dans une colonne correspondant à la valeur estimée. Cette étape se déroule de manière silencieuse.
- Il existe également une colonne « Parking lot », qui peut accueillir jusqu’à 3 items. Elle peut être utilisée si le participant juge que ce n’est pas le bon moment pour estimer cette user story, ou s’il est nécessaire d’en discuter.
- Au bout de 10 minutes d’atelier, accordez-vous une « pause » prise de recul de 2 minutes pour visualiser la situation dans son ensemble, parcourir les estimations déjà réalisées et procéder à des ajustements si nécessaires, mais toujours en mode silencieux.
- Repartez pour une session « mode individuel » de 10 minutes, en répétant les étapes 3 et 4.
- Lorsque toutes les fiches ont été placées, c’est le moment du dialogue. Ouvrez le débat, discutez des désaccords, des risques et incertitudes que vous voyez. Attention, cette étape ne doit durer que 10 minutes.
5 ) La méthode Big / Uncertain / Small
La méthode Big / Uncertain / Small est parfaite si vous avez besoin d’une estimation rapide mais peu précise.
Je trouve que c’est une bonne manière de commencer à affiner le backlog.
Voici le déroulement :
- Les premières fonctionnalités sont discutées en équipe et une fois qu’un consensus est trouvé, elles sont classées dans 3 catégories : Big (importante), Uncertain (incertain), et Small (petite).
- Le reste des user stories sont distribuées équitablement à chaque participant, qui peut décider sans consulter ses voisins dans quelle catégorie les classer.
- S’ensuit une phase d’épuration, où le positionnement de l’ensemble des fiches est évalué et si quelqu’un juge qu’une fiche n’est pas à sa place, on ouvre le débat jusqu’à trouver un consensus.
6 ) La méthode Dot Voting
La méthode Dot Voting consiste à attribuer un nombre de points (ou de gommettes pour les ateliers physiques) à chaque participant, qu’il pourra ensuite distribuer sur les différentes fonctionnalités.
Voici le déroulement :
- Les user stories sont affichées sur un tableau, devant l’ensemble des participants.
- Chacun peut ensuite distribuer ses points comme il l’entend sur les différentes fonctionnalités. Si on estime qu’une fonctionnalité est plus longue ou plus complexe à réaliser que d’autres, on peut mettre plusieurs points dessus.
- Une fois l’ensemble des points distribués, on fait le total des points de chaque user story. Plus elle a de points, et plus elle demandera d’effort pour la réaliser.
7 ) La méthode TFB / NFC / 1
Cette méthode se rapproche de la méthode Big / Uncertain / Small, sauf que les catégories changent de nom et deviennent : TFB (Too Fucking Big), NFC (No Fucking Clue) et 1 pour 1 sprint.
Voici le déroulement :
- Les premières fonctionnalités sont discutées en équipe et une fois qu’un consensus est trouvé, elles sont classées dans 3 catégories : Too Fucking Big (importante, à redécouper), No Fucking Clue (incertain), et 1 sprint (petite).
- Le reste des user stories sont distribuées équitablement à chaque participant, qui peut décider sans consulter ses voisins dans quelle catégorie les classer.
- S’ensuit une phase d’épuration, où le positionnement de l’ensemble des fiches est évalué et si quelqu’un juge qu’une fiche n’est pas à sa place, on ouvre le débat jusqu’à trouver un consensus.
8 ) L’ordering protocol
Toutes les fonctionnalités sont réparties de manière aléatoire en deux catégories : Basse et Haute.
Chaque participant a ensuite la possibilité d’effectuer une action, et une seule, parmi ces 3 possibilités :
- Déplacer une fiche d’une catégorie à l’autre.
- Lancer une discussion à propos d’une fonctionnalité.
- Passer son tour.
Une fois que tous les participants ont réalisé une action, le classement est définitif.
Cette méthode d’estimation peut être utile pour affiner quelques user stories dans un backlog, à condition que le nombre de user stories soit restreint.
9 ) Le no estimate
Et si vous arrêtiez de faire des estimations ? Voilà la base du mouvement #noestimates, qui prend de plus en plus d’ampleur dans le monde agile.
Cette philosophie née des débats entre deux agilistes experts, Woody Zuill et Neil Killick, tente de moderniser l’approche des estimations.
Plutôt que de faire des estimations coûteuses en temps et par nature forcément imprécises, le mouvement no estimate préfère se concentrer sur la valeur apportée au client, qui est au cœur de l’agilité.
Pour mesurer l’avancement d’un projet agile, on ne se base donc plus sur la vélocité de l’équipe ou le nombre de points de complexité réalisés au fur et à mesure des sprints, mais uniquement sur le nombre de user stories terminées.
Pour aller + loin : Vous vous intéressez au #noestimates ? Je vous invite fortement à lire ce retour d’expérience d’une équipe d’Octo après avoir pratiqué la philosophie no estimate pendant plus d’un an.
