Le planning poker

A quoi ça sert ?

Le planning poker est un outil collaboratif permettant d’estimer de façon relative une story et de faire discuter l’équipe avant de l’intégrer dans un sprint et ainsi avoir une compréhension mutuelle.

L’estimation peut être utile pour faire de la projection comme, par exemple, un plan de release en utilisant la vélocité.

Qu’est ce qu’un point ?

Derrière les points, il se cache une multitude de choses.

Par exemple, l’acronyme CURSE le décrit de la façon suivante:

• Complexity (Complexité)
• Uncertainly (Incertitude)
• Risk (Risque)
• Scope (Périmètre)
• Effort

Pour chaque équipe, le point n’a pas la même valeur. Ce n’est donc pas pertinent de comparer la vélocité d’une équipe à une autre.

L’erreur fréquente est de convertir les points en jours et vice versa. L’objectif des points est justement de se détacher du temps.

Idéalement, les estimations sont internes à l’équipe, et je serais d’avis d’éviter de les communiquer aux stakeholders ou managers car, par méconnaissance, ces points peuvent être utilisés étrangement, en ramenant par exemple la vélocité par développeur, ou par jour…

Les cartes

Les cartes de planning poker utilise la suite de Fibonacci : 1,2,3,5,8,13,21,100.

Cette suite amène une meilleure estimation qu’une suite linéaire (1,2,3,4,5,6,7,8,9,10), car plus les développements sont gros, plus c’est compliqué d’être précis et de faire un choix. Il serait par exemple difficile de savoir si une story fait plutôt 6 que 5…

Note: Des jeux remplacent la carte 21 par la carte 20.

Déroulement

Le Product Owner présente la story et échange avec l’équipe et le scrum master peut rappeler la ou les référence.

L’équipe vote en même temps à l’aide des cartes du planning poker.

Si les votes sont très étendus, le Scrum master demande, aux extrêmes, leurs points de vue afin de comprendre l’écart. Idéalement, cette discussion peut-être timeboxée.

Un deuxième tour permet de voir si les discussions ont aboutis à un consensus.

Si au bout d’un certain temps, les estimations restent trop étendues, il se peut que

• La story ne soit pas prête => dans ce cas, il faut la revoir pour la proposer au sprint suivant
• La story est claire mais la solution technique demande une investigation => Dans ce cas, on peut prévoir un spike (exploration technique) ou un POC (Proof Of Concept) dans le sprint précédent la planification de la story.

A noter que les poc et les spikes ne sont pas soumis à l’estimation en point. Il est préférable de les timeboxer. Par exemple, on peut décider de passer 48h sur un spike durant le sprint.

La référence

Je trouve que la planning poker est plus simple quand l’équipe a une ou plusieurs story de référence.

Les story de référence doivent être parfaitement comprises par tous les membres de l’équipe et revue de temps en temps.

Idéalement, on peut avoir une petite story et une grosse story.

On mets arbitrairement un nombre de point pour les 2 story, par exemple:

• La petite story : 2 points
• La grosse story : 8 points (L’effort estimé est 4 fois plus fort que la story à 2 points)

Cette référence permet:

• D’accélérer le processus de vote,
• De rendre le système de points compréhensible pour un nouveau membre de l’équipe.

Conclusion

Le planning poker est un atelier ludique mais les points recèlent une complexité difficile à appréhender. Ces points peuvent également être sujets à des utilisations détournées. Il faut donc bien garder à l’esprit que cette technique permet de faire des projections rapides. Comme toutes estimations, elles ne sont pas justes mais permet de se projeter dans la release, et d’amorcer une discussion sur les story pour arriver à une compréhension mutuelle.

Enfin, Merci à l’équipe Xebia pour les magnifiques cartes de planning poker !