Planning Poker (scrum poker)

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 fonctionne ce fameux planning poker ensemble.

Vous pouvez regarder la vidéo de la minute agile sur le sujet :

Quand faire le planning poker / scrum poker ?

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

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.

D’ailleurs, 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 le planning poker

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

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 de planning poker

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 user story 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 points d’effort de la user-story. Les développeurs devront se poser la question : « Quelle est le point d’effort selon moi pour réaliser cette user-story ? ».

Concept des points d’effort en planning poker

Le point d’effort d’une user story (ou d’une tâche technique) va inclure différentes notions que les développeurs devront prendre en compte pour faire l’estimation de celle-ci :

• l’effort à faire pour développer la demande
• la difficulté (complexité) que peut comporter la demande
• les risques qu’on imagine pouvoir rencontrer lors du développement de l’US
• les éventuelles inconnues existant au moment de l’estimation
• les dépendances potentielles avec des éléments extérieurs

Il faut accepter que le point d’effort est une notion « abstraite » qui ne peut pas être comparé à un nombre de jours homme. Mais elle permet cependant de faire de la prédictibilité.

Oui, le point d’effort prend bien une notion de temps contrairement à ce que l’on peut lire parfois. Mais son estimation ne se base pas que dessus et cette notion de temps n’est pas matérialisée par 1 point d’effort = 1 jour.

Utiliser la suite de Fibonacci en planning poker

Pour noter le point d’effort, 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 en planning poker

Maintenant que vous savez tout sur les points d’effort, voilà comment se déroule la séance de planning poker entre les développeurs.

Chaque développeur va choisir son point d’effort 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 lors du planning poker

Tous les participants votent le même point d’effort, on valide alors ce point d’effort 1 sur la user-story.

Consensus 1 lors du planning poker

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

Consensus 2 lors du planning poker

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

A 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. Le développeur qui trouve la demande complexe pourra être aidé si c’est lui qui prendra la user-story ; cela lui fera baisser la point d’effort qu’il avait estimé. 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 le point d’effort de la user-story.

Conclusion scrum poker

Le product owner proposera de faire l’exercice du planning poker sur l’ensemble des user-stories de son backlog qui seront bientôt en développement. En effet, le but du poker planning sera de préparer les prochains Sprint qu’il pourra proposer à l’équipe de développement.

mots clés : poker planning – scrum poker

lien utile : Framing agile