Le « poker planning » est une pratique Scrum qui permet d’évaluer la complexité d’un item du product backlog.
Il s’agit de réunir l’équipe de réalisation, le Product Owner et le Scrum Master dans une même salle et de leur donner à chacun un jeu de cartes contenant habituellement les chiffres suivants : 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 (vous aurez surement l’occasion de récupérer un jeu de cartes donné gracieusement par un sponsor lors d’une prochaine conférence Agile).
L’objectif de la réunion est d’estimer la complexité de chaque item (appelé « user point ») relativement à un item de référence relativement simple et dont la signification est bien maîtrisé par l’équipe. De façon arbitraire, l’item de référence reçoit la valeur 3 ou 5. Ces points correspondent à un effort de réalisation pour l’équipe mais il est impératif que ces points ne représentent pas une valeur de production réelle (des jours ou des heures par exemple).
La procédure pour affecter les « user points » est la suivante:
- Lecture d’un item du backlog par le Prodcut Owner
- Discussion rapide de cet item
- Vote (chaque participant sélectionne une carte et tous les participants montrent la valeur en même temps)
- Discussion sur les écarts (« J’ai mis 2 et toi 13 … pourquoi penses-tu que cet item est si compliqué ? »)
- Nouveau vote
- En cas d’accord, le Product Backlog est mis à jour avec la valeur sur laquelle l’équipe s’est accordée
- En cas de désaccord, l’item est mis de coté, il faudra faire une travail complémentaire d’analyse … mais en dehors de la réunion actuelle
- Lecture de l’item suivant
- …
L’estimation en points permet à l’issue de l’itération de calculer la vélocité de l’équipe en additionnant les points des items terminés (et uniquement ceux complètement terminés).
Ce que j’apprécie particulièrement dans la technique du planning poker, c’est sa capacité à créer des moments d’échanges intenses au sein de l’équipe. En effet, la discussion permet généralement d’enrichir les critères de recette (« acceptance criteria ») de l’item du backlog – Beaucoup plus utile que de discuter du libellé de l’item (« user story ») – et de converger très rapidement sur la compréhension de cet item par l’équipe de réalisation.
Hier, lors d’une formation en intra, j’ai proposé à une équipe de 4 personnes un exercice pratique pour estimer des points de chien (« Dog points ») à l’aide du planning poker … et encore une fois la puissance de la pratique s’est révélée être sa capacité à générer des échanges au sein de l’équipe pour converger très rapidement sur la compréhension du besoin et l’estimation de la complexité.
Salut Alexandre,
Merci pour ce billet sur le planning poker. J’apprécie également beaucoup cette technique qui permet à l’équipe d’effectuer ensemble l’analyse de détail des tâches à réaliser.
On peut encore rajouter que l’équipe doit sur mettre d’accord sur deux points avant de commencer:
– Que signifie « accord sur les estimations »? Un écart de 1 ou 2 cartes (par exemple 3-3-5-3-5-8) peut être considérer comme ok (moyenne = 4.5). Dans la pratique, on remarque qu’il est difficile d’obtenir de tous les membres de l’équipe exactement la même estimation
– Que signifie « done »? Afin d’avoir des estimations les plus proches possibles les unes des autres, il faut que tout le monde soit d’accord sur la définition du « done » (ce qui est normalement le cas d’une équipe avec une grande maturité, mais pas forcement lors d’une première expérience agile)
Il y a aussi les cartes « ? » et « café » (aucune idée, impossible de fournir une estimation et ça fait passer une heure que l’on estime notre backlog, j’ai besoin d’une pause), qui est bon d’utiliser à bon escient.
Lorsque les estimations dépassent 20 et même si tout le monde est plus ou moins d’accord (par exemple 20-40-20-20-20-40), il bon de se demander si la tâche ne devrait pas être découpée et ré-estimée.
Salutations,
Alain
Suisse
Après avoir essayé les user points j’ai préféré les « jours idéaux » qui représentent une journée sans interruption sur la tâche. Parceque lors du découpage de la story en tâche on estime en heure forcément influencé par le nombre de user points et parceque lors de l’estimation l’équipe est plus à l’aise avec ces « jours idéaux ».
J’aimerais comprendre ce qui rend si impératif « que ces points ne représentent pas une valeur de production réelle » ou alors peut-on considérer les « jours idéaux » comme sans valeur réelle.
Ou enfin, c’est pas très important si ça marche c’est l’essentiel ?