Tout ce qu'il faut savoir pour animer une session de Planning Poker : règles, rôles, valeurs des cartes, déroulement étape par étape et conseils pour le remote.
Qu'est-ce que le Planning Poker ?
Le Planning Poker est une technique d'estimation par consensus pour les équipes agiles. Inventée par James Grenning en 2002 et popularisée par Mike Cohn, elle aide les équipes Scrum à estimer l'effort relatif des user stories pendant le sprint planning.
Le principe est simple : chaque membre de l'équipe vote simultanément avec des cartes numérotées. La révélation simultanée empêche le biais d'ancrage et encourage une réflexion indépendante et honnête.
Les règles
Le Planning Poker n'a pas de "règlement officiel" unique, mais les règles communément acceptées viennent du livre Agile Estimating and Planning de Mike Cohn et des pratiques décrites dans le Scrum Guide. Voici le processus standard.
Qui participe ?
Trois rôles sont impliqués :
- Scrum Master : facilite la session, gère le timer, révèle les cartes et maintient la discussion sur les rails.
- Votants : les membres de l'équipe de développement qui travailleront effectivement sur les stories. Ce sont les seuls qui votent.
- Observateur : toute personne qui souhaite suivre la session sans voter. Typiquement le Product Owner, un stakeholder ou un manager. Ils peuvent poser des questions mais ne tiennent pas de cartes.
Le Product Owner présente les stories mais ne vote pas. Sa présence est essentielle pour le contexte, mais son estimation pourrait influencer l'équipe.
Les valeurs des cartes
Le jeu standard suit une suite de Fibonacci modifiée :
| Carte | Signification |
|---|---|
| 0.5 | Tâche triviale, quasiment terminée |
| 1 | Très petit effort, bien compris |
| 2 | Petit effort |
| 3 | Effort modéré |
| 5 | Effort moyen, quelques inconnues |
| 8 | Effort important, complexité significative |
| 13 | Très grand, envisager de découper |
| 21 | Énorme, doit être découpé avant d'entrer dans un sprint |
| ? | Pas assez d'informations pour estimer |
| Café | L'équipe a besoin d'une pause |
Les écarts croissants entre les valeurs reflètent une vérité fondamentale : plus une tâche est grosse, moins l'estimation est précise. Distinguer un 7 d'un 8 n'a pas de sens. Distinguer un 5 d'un 13, si.
Déroulement étape par étape
Étape 1 : Présenter la story. Le Product Owner lit la user story à voix haute, y compris les critères d'acceptation. L'équipe pose ses questions de clarification. Cette phase dure 2-3 minutes maximum.
Étape 2 : Estimation silencieuse. Chaque votant choisit en secret la carte qui représente le mieux l'effort. Pas de discussion, pas de coup d'oeil. C'est là où la réflexion indépendante se produit.
Étape 3 : Révélation simultanée. Toutes les cartes sont révélées en même temps. C'est le mécanisme central qui empêche le biais d'ancrage.
Étape 4 : Discuter les divergences. Si les estimations diffèrent significativement (par exemple, un 3 et un 13 dans le même tour), les votants aux extrêmes expliquent leur raisonnement. Raisons courantes de divergence :
- Compréhension différente des critères d'acceptation
- Complexité technique cachée repérée par une seule personne
- Dépendance ou intégration manquante
- Hypothèses différentes sur le périmètre
Étape 5 : Re-voter. Après la discussion, l'équipe vote à nouveau. La plupart des stories convergent en 1-2 tours. Si un troisième tour montre encore un grand écart, la story a probablement besoin d'être affinée ou découpée.
Étape 6 : Enregistrer et passer à la suite. Le Scrum Master enregistre l'estimation validée et passe à la story suivante.
Quand arrêter de discuter
Une erreur courante est de chercher le consensus parfait. Tout le monde n'a pas besoin d'être sur la même carte. Si l'équipe passe d'un écart 3-13 à un écart 5-8 après discussion, c'est suffisant. Prenez la valeur la plus haute et avancez.
Bonne règle : si la discussion dépasse 3 minutes sur une seule story, la story n'est pas prête à être estimée. Mettez-la de côté pour un refinement.
Gestion du temps
Les sessions d'estimation doivent être courtes et concentrées :
- Cible : 1-2 minutes par story en moyenne
- Durée de session : 60-90 minutes maximum avant que la qualité baisse
- Timer : utilisez un compte à rebours de 2 minutes par story pour maintenir le rythme
- Pause : prévoyez 5 minutes de pause toutes les 45 minutes
Si votre équipe dépasse régulièrement ces limites, le backlog nécessite probablement un meilleur refinement en amont.
Compter les votes
Après la révélation, le facilitateur peut utiliser plusieurs approches :
- Consensus : tout le monde montre la même carte. Enregistrez immédiatement.
- Quasi-consensus : valeurs à un pas d'écart (ex: 5 et 8). Prenez la valeur la plus haute ou la médiane.
- Grand écart : valeurs à plus de deux pas (ex: 3 et 13). Discutez et revotez. Ne faites jamais la moyenne.
Ne faites jamais la moyenne des estimations. "La moyenne de 3 et 13 fait 8" efface précisément l'information que le Planning Poker est conçu pour révéler : que l'équipe n'est pas d'accord sur ce que cette story implique.
Erreurs courantes
Estimer en heures déguisées en points. "C'est un 5 parce que ça prendra 5 jours." Non. Les story points mesurent la complexité relative, pas la durée.
Laisser le senior parler en premier. Même avec la révélation simultanée, le langage corporel et le timing peuvent fuiter de l'information. La révélation simultanée stricte élimine ce problème.
Sauter la discussion après une divergence. La discussion est là où se trouve la vraie valeur. Un re-vote silencieux sans discussion n'est qu'une moyenne avec des étapes supplémentaires.
Estimer des stories qui ne sont pas prêtes. Si les critères d'acceptation sont absents ou vagues, aucune technique d'estimation n'aidera. Renvoyez la story en refinement.
Sessions marathon. Après 90 minutes, la qualité des estimations baisse significativement. Deux sessions concentrées de 45 minutes valent mieux qu'une session de 3 heures.
Le Product Owner qui vote. Le PO fournit le contexte mais ne devrait pas tenir de cartes. Son vote, même involontairement, peut ancrer l'équipe.
Planning Poker pour les équipes remote
Le Planning Poker à distance suit les mêmes règles, mais l'outillage compte davantage :
- Utilisez un outil dédié comme Planning Poker Online pour que les votes soient vraiment cachés jusqu'à la révélation
- Gardez les caméras vidéo allumées pour que le Scrum Master puisse lire l'ambiance
- Utilisez le timer intégré pour maintenir le rythme
- Partagez la description de la story à l'écran, pas seulement à l'oral
- Envisagez l'estimation asynchrone pour les gros backlogs : chaque votant estime indépendamment, et l'équipe ne discute que des stories avec des estimations divergentes
Lisez notre article dédié sur le Planning Poker en remote.
Planning Poker vs autres techniques
| Technique | Idéal pour | Vitesse | Précision |
|---|---|---|---|
| Planning Poker | Sprint planning, 10-20 stories | Moyenne | Haute |
| T-Shirt Sizing | Roadmap, gros backlogs | Rapide | Basse |
| Estimation par affinité | Estimation initiale de backlog, 30+ stories | Rapide | Moyenne |
| Dot Voting | Priorisation, pas d'estimation | Rapide | N/A |
| Bucket System | Très gros backlogs, 50+ stories | Rapide | Moyenne |
Le Planning Poker est le meilleur choix quand vous avez besoin d'estimations de qualité sur un nombre gérable de stories. Pour des backlogs plus importants, commencez par le T-Shirt Sizing ou l'estimation par affinité, puis affinez avec le Planning Poker quand les stories approchent du sprint.
Aide-mémoire
- Le PO présente la story (2-3 min)
- L'équipe pose ses questions
- Chacun choisit une carte en silence
- Révélation simultanée
- Si écart > 2 niveaux : discuter les extrêmes (2-3 min)
- Re-voter si nécessaire (max 3 tours)
- Enregistrer l'estimation, story suivante
Essayez maintenant
Prêt à lancer votre première session ? Créez une session Planning Poker gratuite en quelques secondes. Sans inscription, partagez le lien avec votre équipe et commencez à estimer.
