[Total : 1    Moyenne : 5/5]

Le Planning Poker Card est une méthode ludique et consensuelle pour planifier les projets. Très utilisé lors des SCRUM, cet outil peut être utilisé pour tout type de projets.

Le Planning Poker Card est une méthode d’estimation des délais développée par M. Cohn1 qui l’a lui même adaptée du « planning game » utilisé dans la méthode XP. L’objectif est d’estimer en équipe les délais de réalisation des projets.

Le principe est plutôt simple : chaque personne de l’équipe va faire une estimation. Cette estimation est ensuite confrontée avec les estimations des autres personnes pour ne retenir plus qu’une valeur.

Déroulement

1 – Réunir l’équipe

La première étape sera de réunir l’équipe projet. Toutes les personnes de la SCRUM Team ainsi que le Product Owner doivent être présentes.

Il est à noter que pour une bonne estimation, il est conseillé d’être au moins 5 personnes.

2 – Distribuer les cartes

A chaque personne, on va donner un jeu de cartes, chacune comportant une valeur : 0, 1, 2, 3…

Lles valeurs utilisées suivent approximativement la loi de Fibonacci : ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞.

3 – Présentation et échange de la User Story

Le Product Owner va présenter la User Story. L’objectif est que tout le monde comprenne le sujet et soit d’accord l’attendu. L’équipe devra poser toutes les questions nécessaire pour ne pas laisser de zones d’ombres.

4 – Choisir le thème de choix

Le Planning Poker Card est utilisé à deux fins :

  • Soit pour définir le nombre de tâches nécessaire pour réaliser la Story. C’est le cas lorsqu’une User Story est complexe que l’on va découper en « Story Point ».
  • Soit pour identifier le nombre d’heures ou jours nécessaire pour réaliser une tâche. Ce sont les « Ideal Day », qui représentent le délai de réalisation de chacune des User Story ou Story Point.

5 – Effectuer l’estimation

L’ensemble des personnes de l’équipe va effectuer une estimation du nombre de Story Point ou d’Ideal Day en présentant de manière simultanée la carte avec la valeur retenue correspondante.

Le délai de réflexion est de l’ordre de 1 à 2 minutes.

6 – Valider une « valeur »

Toujours en groupe, on va comparer, analyser et échanger sur les valeurs proposées pour n’en retenir qu’une. Le but étant d’obtenir le consensus de manière conviviale et rapide, en laissant s’exprimer chacun et justifier le choix de son chiffre :

  • Si toutes les estimations sont convergentes, alors on validera le résultat tel quel.
  • Si les estimations ne convergent pas, les discussions reprennent particulièrement entre les personnes ayant les plus grands écarts de points.

Quelques règles importantes

Règle 1 : Avoir une connaissance similaire du sujet

Une mauvaise estimation peut être le fait d’un manque de maîtrise du sujet, ou le niveau de maîtrise trop disparate. Le fait que le Product Owner détaille la User Story permet de réduire le risque, mais pas de l’éliminer.

Ainsi, si le niveau de connaissance est trop inégalement réparti, on pourra :

  • Soit faire des paires de personne (un sénior avec un junior) pour effectuer l’estimation.
  • Soit les personnes choisissent les stories qu’ils veulent estimer (avec tout de même un minimum de 5 personnes par estimation) en fonction de leur niveau de connaissance.

Règle 2 : Assurer l’échange et le consensus

Autre point essentiel, faire en sorte que tout le monde puisse s’exprimer librement en évitant le consensus mou. L’animateur de la session devra s’en assurer et limiter les temps de parole si nécessaire.

Source

1 – M. Cohn (2005) – Agile estimating and planning

V. Messager Rota (2014) – Architecte Logiciel

Share This