Comment animer une séance de Planning Poker

Les votants sont les personnes qui réaliseront le travail : développeurs, testeurs, designers… Ce sont elles qui estiment, car ce sont elles qui connaissent l’effort réel.

• Le facilitateur (souvent le Scrum Master) anime la séance, gère le temps et déclenche la révélation des cartes. Il peut voter s’il fait partie de l’équipe de réalisation.
• Le Product Owner présente les stories et répond aux questions métier. En général, il ne vote pas, pour ne pas orienter l’estimation.
• Des observateurs (managers, parties prenantes) peuvent suivre la séance sans voter.

La qualité d’une séance se joue avant qu’elle commence. Le Product Owner sélectionne les stories à estimer, idéalement les plus prioritaires du backlog, et s’assure que chacune a un titre explicite, une description et des critères d’acceptance.

• Partagez la liste des stories un ou deux jours avant, pour que l’équipe puisse la parcourir.
• Choisissez le jeu de cartes : la suite de Fibonacci pour des story points, les tailles de t-shirt pour une estimation plus grossière.
• Définissez une story de référence, déjà réalisée, que tout le monde connaît. Elle sert d’étalon : « est-ce plus gros ou plus petit que la story X ? ».
• Prévoyez 45 minutes à 1 heure. Au-delà, l’attention baisse et les estimations perdent en qualité.

1. 1Le Product Owner présente la story : le besoin, la valeur attendue, les critères d’acceptance.
2. 2L’équipe pose ses questions. On clarifie le périmètre, sans encore parler de chiffres.
3. 3Chacun choisit une carte en secret. Personne n’annonce sa valeur à voix haute.
4. 4Le facilitateur révèle toutes les cartes en même temps.
5. 5Si les votes convergent, l’estimation est retenue. Sinon, on discute puis on revote.

La révélation simultanée est le cœur de la méthode : elle évite l’effet d’ancrage, où le premier chiffre annoncé (souvent par la personne la plus expérimentée) influence tous les autres.

Un écart important, par exemple un 2 et un 13 sur la même story, n’est pas un problème : c’est le signe que l’équipe n’a pas la même compréhension du travail. C’est précisément ce que le Planning Poker cherche à révéler.

• Demandez d’abord aux votes extrêmes (le plus bas et le plus haut) d’expliquer leur choix. Souvent, l’un a repéré une difficulté que l’autre ignorait, ou l’inverse.
• Après la discussion, revotez. Deux ou trois tours suffisent en général à converger.
• Si l’équipe ne converge toujours pas, retenez la valeur majoritaire, ou la plus haute par prudence, et passez à la suite.
• Si la story reste floue, ne l’estimez pas : renvoyez-la au Product Owner pour qu’elle soit précisée ou découpée.

La carte « ? » signale qu’on manque d’informations pour estimer, et la carte « ☕ » qu’une pause serait la bienvenue. Prenez-les au sérieux : elles en disent long sur l’état de la séance.

• Laisser le Product Owner ou un manager voter : leur avis pèse plus lourd et biaise l’équipe.
• Annoncer un chiffre avant la révélation (« moi je dirais 5… »), ce qui annule tout l’intérêt du vote secret.
• Débattre sans fin d’une différence entre 3 et 5 : l’estimation n’a pas besoin d’être parfaite, seulement utile.
• Convertir les story points en heures ou en jours. Les points mesurent un effort relatif, pas une durée.
• Comparer les points entre équipes : chaque équipe a sa propre échelle.
• Estimer des stories trop grosses. Au-delà de 13, il vaut mieux découper la story.

Reportez les estimations dans votre outil de suivi (Jira, Azure DevOps, Linear…) : avec The Planning Poker, le récapitulatif de la séance s’exporte en CSV. Au fil des sprints, comparez les points prévus aux points réalisés pour mesurer la vélocité de l’équipe et rendre les prochaines planifications plus fiables.