Planning Poker : guide complet, cartes Fibonacci et préparation au PSM I

Le Planning Poker — aussi appelé Poker Planning ou Scrum Poker — est la technique d'estimation collective la plus utilisée dans les équipes agiles. Popularisée par Mike Cohn en 2005, elle combine un Scrum Team, des cartes suivant la suite de Fibonacci et un vote simultané pour estimer des User Stories en Story Points. Ce guide couvre tout : principe, déroulement d'une session, cartes, exemples concrets, format présentiel et à distance, outils en ligne, erreurs à éviter et pièges du PSM I.

Qu'est-ce que le Planning Poker ?

Le Planning Poker est une technique d'estimation agile collective, gamifiée et anti-ancrage. Chaque Developer choisit en secret une carte représentant son estimation en Story Points, puis toutes les cartes sont révélées simultanément. Les écarts entre estimations déclenchent une discussion structurée qui fait émerger les hypothèses, les risques et les inconnues jusqu'au consensus.

L'outil a été formalisé par James Grenning en 2002 puis popularisé par Mike Cohn dans son livre Agile Estimating and Planning (2005). Il est aujourd'hui la pratique d'estimation la plus répandue en Scrum, mais aussi en Kanban, XP ou SAFe.

Pourquoi utiliser le Planning Poker ?

Les autres techniques d'estimation (moyennes, votes à main levée, estimation par un expert) souffrent d'un défaut majeur : l'effet d'ancrage. La première valeur exprimée influence toutes les suivantes. Le Planning Poker corrige cinq biais classiques :

• Effet d'ancrage — vote secret + révélation simultanée.
• Effet de groupe — chacun vote indépendamment.
• Domination hiérarchique — un senior ne peut pas imposer son chiffre.
• Sous-estimation optimiste — l'écart entre votes révèle les risques cachés.
• Estimation par un seul expert — l'intelligence collective améliore la fiabilité.

Story Points et Planning Poker

Le Planning Poker sert à estimer en Story Points — une unité relative qui agrège complexité, quantité de travail et incertitude. Pas des heures, pas des jours-hommes. L'estimation relative permet à l'équipe de comparer une story à des stories de référence déjà réalisées, sans se rattacher à une durée illusoire.

Une story de référence de 3 points chez votre équipe ne vaut pas 3 points chez une autre équipe. C'est normal : les Story Points sont propres à chaque équipe.

Pourquoi la suite de Fibonacci ?

La suite de Fibonacci modifiée (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) est celle utilisée par défaut. L'écart entre chaque valeur croît volontairement, ce qui reflète la réalité de l'estimation : plus une story est grosse, moins on peut la mesurer finement.

Les cartes du Planning Poker

Un jeu de Planning Poker standard contient 13 cartes par joueur : les valeurs Fibonacci et deux cartes spéciales.

• ? — je ne comprends pas la story ; il faut la clarifier avant tout vote.
• ☕ — je demande une pause ; l'attention baisse, il est temps de couper.
• 0 — pas de travail (la story est déjà terminée).
• ½ — quelques minutes à peine (utilisé rarement).
• 100 — trop gros, à découper.

Déroulement d'une session de Planning Poker

Une session type dure entre 60 et 90 minutes et traite 10 à 20 stories. Elle se déroule idéalement pendant le Product Backlog Refinement, pas en Sprint Planning (dont la timebox est déjà chargée).

1. Le Product Owner présente la User Story et les critères d'acceptation.
2. Les Developers posent des questions — le PO répond, clarifie, ajuste.
3. Chaque Developer choisit sa carte, face cachée.
4. Révélation simultanée.
5. Le facilitateur donne la parole au vote le plus bas, puis au vote le plus haut.
6. Après discussion, nouveau tour de vote.
7. Le processus s'arrête au consensus (ou après 3 tours — sinon on reporte).

Exemple complet d'estimation

Prenons une User Story concrète et simulons un tour complet de Planning Poker avec un Scrum Team de 4 Developers.

Ce cas illustre parfaitement pourquoi le Planning Poker fonctionne : sans Bob, la story aurait été estimée à 3 ou 5 points, alors qu'elle en vaut probablement 8. Le vote secret a permis à Bob d'exprimer un risque sans être influencé par les autres.

Que faire en cas d'écart important ?

Un écart important (par exemple 3 ↔ 13) est une bonne nouvelle : il signale une information manquante. Le facilitateur applique cette procédure :

1. Donner la parole au vote le plus bas : « Pourquoi 3 ? »
2. Donner la parole au vote le plus haut : « Pourquoi 13 ? »
3. Laisser les autres Developers ajouter leur point de vue.
4. Éventuellement, rappeler la Definition of Done pour aligner sur le périmètre réel.
5. Re-voter — sans imposer de valeur intermédiaire.

Planning Poker en présentiel

En salle physique, on utilise un vrai jeu de cartes Planning Poker (Mountain Goat Software, Scrum.org, éditions open source). Chaque Developer reçoit un deck complet.

• Avantage : engagement fort, dimension ludique, discussions plus rapides.
• Avantage : lecture du langage non-verbal des collègues.
• Inconvénient : trace écrite manuelle, moins traçable.
• Inconvénient : impossible si un membre est à distance.

Planning Poker à distance

À distance, un outil en ligne remplace les cartes physiques. Le principe reste identique : vote secret, révélation simultanée, discussion des écarts.

• Avantage : traçabilité (log des votes horodatés).
• Avantage : compatible avec des équipes hybrides ou multi-sites.
• Inconvénient : rythme plus lent (délai UI, connexion).
• Inconvénient : perte du langage non-verbal.

Les meilleurs outils de Planning Poker en ligne

Le marché propose une dizaine d'outils gratuits ou freemium. Voici un panorama neutre — aucun n'est officiellement recommandé par Scrum.org.

• PlanningPokerOnline.com — le plus connu, aucun compte requis.
• Miro + template Scrum Poker — parfait si l'équipe utilise déjà Miro.
• Jira + plugin Poker — rattache les estimations aux issues Jira.
• Azure DevOps Estimate — intégration native au backlog ADO.
• Parabol — SaaS combiné rétrospective + poker.
• Scrumpy, PokerNoker, FunRetro — alternatives légères sans inscription.

Les erreurs fréquentes

1. Faire la moyenne des votes — cache la divergence et neutralise l'apport du poker.
2. Laisser le PO ou le SM voter — viole la responsabilité des Developers.
3. Convertir les Story Points en heures publiquement — détruit l'estimation relative.
4. Débattre entre 12 et 13 points — la précision fine est illusoire au-delà de 8.
5. Estimer 20+ stories dans une seule session — fatigue, baisse de qualité.
6. Ignorer la carte « ? » — signe que la story n'est pas prête (Definition of Ready).
7. Fixer un objectif de vélocité — pousse l'équipe à gonfler ses estimations.
8. Estimer en Sprint Planning au lieu du refinement — mange la timebox.
9. Comparer les vélocités entre équipes — anti-pattern managérial classique.
10. Enchaîner les tours sans discussion — supprime la vraie valeur de l'outil.

Planning Poker et pièges du PSM I

Questions type examen PSM I

Ressources et maillage