Planning Poker : estimer vos user-stories

Ecrit par << Paquet Judicaël >>

Il existe une méthode d’estimation de user-story devenue très populaire dans l’univers Scrum : le Planning Poker ; on l’appelle aussi scrum poker. Nous allons découvrir comment celle-ci fonctionne ensemble.

Quand ?

Certains estiment leurs user-story lors de la Sprint Planning mais il est à ce jour recommandé de faire une Product Backlog Refinement pour affiner les user-story.

En quelques mots, la Product Backlog Refinement (Grooming) est une cérémonie Scrum que nous faisons généralement 1 fois par semaine qui permet d’affiner les user-story et de les estimer. Cela permet d’avoir une Sprint Planning de meilleure qualité avec un Product Owner qui sait déjà exactement ce qu’il mettra dans le Sprint qui démarre.

Voici un article sur le sujet si vous voulez en savoir plus sur  la Product Backlog Refinement (Grooming) : La Product Backlog Refinement

Matériel supplémentaire nécessaire

Pour estimer ses user-story avec le PlanningPoker, il vous faudra avoir des cartes planning poker de ce type :

planning poker cartes
planning poker cartes

Vous pourrez également trouver des applications sur vos téléphones portables en cherchant : Planning Poker.

Chaque développeur aura son jeu (ou application) de carte afin de pouvoir participer aux votes.

On lance la séance

Le Product Owner va présenter une user-story qu’il a intégralement terminé (selon la définition of ready) aux développeurs afin qu’ils puissent l’estimer. L’idéal est de présenter également le contenu de celle-ci en projetant le logiciel utilisé.

Après l’explication concrète, les développeurs pourront poser des questions si la user-story n’est pas suffisamment claire ; le Product Owner répondra aux questions et notera celles-ci pour compléter la user-story.

Incomplète

Si la user-story est incomplète et ne permet aux développeurs de l’estimer, le Product Owner devra garder sa user-story, la compléter et revenir avec à la séance suivante.

Il ne faut pas estimer une carte qui est incomplète ou sur laquelle il reste encore quelques questions. Cela posera des soucis à la suite du projet. Il est préférable de prendre un retard sur une fonctionnalité que de perturber toute la chaîne de production.

Complète

Les développeurs vont alors voter avec leurs cartes dès qu’ils n’auront plus de questions sur la user-story.

Pour voter, chaque développeur va choisir une notre de complexité (appelée également points d’effort) de la user-story. Les développeurs devront se poser la question : « Quelle est la complexité selon moi pour réaliser cette user-story ? ».

Concept de la complexité

Contrairement à de nombreuses méthodes existantes, dans le monde Agile on aime jauger en complexité et non en temps de réalisation. On est nombreux à penser par expérience que d’estimer en temps de réalisation n’a pas trop de sens car la plupart des projets ne sont pas livrés à temps malgré les estimations (ou pas livré avec la même force de frappe initialement prévue).

Certaines méthodes de gestion de projet proposent même d’ajouter 80% de temps à une estimation technique pour combler l’enthousiasme des développeurs qui ont tendance à estimer petit et également pour prévoir les éventuelles absences.

La complexité est la difficulté qu’on estime pour pouvoir réaliser une user-story. Il ne faut surtout pas imaginer le temps que ça pourrait prendre mais uniquement la difficulté pour la réalisation.

Si dans de nombreux cas, une user story complexe sera plus longue qu’une user story simple, cela ne sera pas toujours le cas. Il sera possible d’avoir une user-story très simple à faire mais qui prendra du temps et inversement.

Pas d’inquiétude, il y a bien des possibilités pour faire des roadmap avec cette méthode et qui sont tout aussi bonne qu’avec les autres types d’estimation.

Utiliser la suite de Fibonacci en planning poker

Pour noter la complexité, nous allons utiliser la suite de Fibonacci :  0, 1, 1, 2, 3, 5, 8, 13, 21… En général, la plupart des équipes qui font des Sprint de deux semaines utilisent la suite 1, 2, 3, 5, 8 et 13 ; ces équipes estiment que 21 seraient alors la note pour dire que la user-story est trop grosse et qu’un découpage est indispensable.

Cette suite a été utilisée car plus on grossit sa note et plus on estime qu’il y a une incertitude. Quand une demande est très complexe, inutile de choisir entre 12 et 13, ça n’aurait pas trop de sens ; on préfère dire que c’est 13 tout simplement.

Déroulement des votes

Maintenant que vous savez tout sur les complexités, voilà comment se déroule la séance de vote entre les développeurs.

Chaque développeur va choisir sa complexité dans son coin, et l’ensemble des développeurs vont montrer leur note à l’ensemble de l’équipe au même moment.

Voici les cas possibles et les résultats à en conclure.

Osmose parfaite

poker planning osmose parfaite
planning poker osmose parfaite

Tous les participants votent la même complexité, on valide alors cette complexité 1 sur la user-story.

Consensus 1

poker planning consensus
planning poker consensus

Tous les participants ne votent pas la même chose mais l’écart reste correct (soit pas plus de 2 rangs d’écart entre la plus petite complexité et la plus grande). On validera alors la complexité 5 soit celle du milieu.

Consensus 2

poker planning consensus
planning poker consensus

Tous les participants ne votent pas la même chose mais l’écart reste correct (soit 1 seul rang d’écart entre la plus petite complexité et la plus grande). On validera alors la complexité 5 soit la plus haute même si seul 1 participant a mis cette complexité.

A revoter

poker planning à revoter
planning poker à revoter

Tous les participants ne votent pas la même chose et l’écart est trop grand. On va demander aux développeurs de discuter entre eux afin de trouver un consensus logique (promesse d’aide au développeur qui trouve la demande complexe si c’est lui qui prendra la user-story par exemple afin qu’il baisse sa complexité). Parfois la discussion montrera aussi que la user-story était peut-être pas si bien comprise et que la difficulté avait été sous-estimée.

Après une bonne discussion, les développeurs revoteront la complexité de la user-story afin de se retrouver dans l’un des 3 premiers cas cités.

Conclusion Planning Poker

Le Product owner proposera de faire l’exercice du planning poker sur l’ensemble des user-story de son backlog. Ceci dans le but de préparer les prochains Sprint qu’il proposera aux développeurs.

mots clés : poker planing

4 réponses sur “Planning Poker : estimer vos user-stories”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.