Une session d'estimation déguisée en partie de cartes. Spoiler : c'est bien plus efficace qu'un tableau Excel.
Le concept en deux mots
Le Planning Poker (ou Scrum Poker) est une technique d'estimation collaborative utilisée dans les équipes agiles. L'idée : chaque membre de l'équipe vote simultanément sur la complexité d'une user story a l'aide de cartes numérotées.
Les valeurs sur les cartes suivent généralement la suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21... mais on y reviendra.
Le Planning Poker n'estime pas des durées. Il mesure la complexité relative d'une tâche par rapport a d'autres, exprimée en story points. C'est une distinction fondamentale : on ne dit pas "ça prendra 3 jours", on dit "c'est environ deux fois plus complexe que cette autre story qu'on a estimée a 3".
D'ou vient le Planning Poker ?
La technique a été inventée par James Grenning en 2002. Développeur et consultant agile (il fait partie des signataires du Manifeste Agile), Grenning cherchait un moyen d'impliquer toute l'équipe dans les estimations, pas seulement les deux ou trois personnes les plus expérimentées.
Son article original, Planning Poker or How I Learned to Stop Worrying and Love the Deadline, décrit le problème clairement : dans les méthodes traditionnelles, les estimations sont souvent faites par un expert seul ou par un petit groupe, ce qui crée des angles morts. Grenning a combiné trois idées :
- L'estimation par expertise (Wideband Delphi) : chaque participant estime indépendamment.
- Le vote simultané : les estimations sont révélées en même temps pour éviter les biais.
- La discussion structurée : les écarts déclenchent un échange avant de revoter.
La technique a été popularisée par Mike Cohn dans son livre Agile Estimating and Planning (2005), qui l'a intégrée dans sa boite a outils Scrum. Depuis, elle est devenue la méthode d'estimation la plus utilisée dans les équipes agiles a travers le monde.
Comment ça se déroule ?
Une session de Planning Poker suit un déroulement précis :
- Le Product Owner présente une user story a l'équipe. Il lit la description, les critères d'acceptation et répond aux premières questions. L'objectif : que tout le monde comprenne ce qui est demandé.
- L'équipe discute brièvement. Les développeurs posent des questions techniques, identifient les dépendances, clarifient les zones d'ombre. Cette phase dure quelques minutes, pas plus.
- Chaque participant choisit une carte en secret représentant son estimation de la complexité.
- Tout le monde retourne sa carte en même temps : c'est le moment de vérité.
- Si les estimations divergent fortement, on discute. La personne qui a mis le plus petit nombre et celle qui a mis le plus grand expliquent leur raisonnement. Ces échanges sont souvent les plus riches de toute la session.
- On revote jusqu'a obtenir un consensus (ou quelque chose d'acceptable pour tout le monde).
En pratique, la plupart des stories convergent en un ou deux tours. Les tickets qui nécessitent trois tours ou plus sont souvent mal définis et gagneraient a être découpés.
Pourquoi le vote simultané change tout
Le vote simultané est la clé du système. Il évite le biais de conformité : si le senior dev annonce "8" en premier, tout le monde risque de le suivre sans réfléchir. En votant en même temps, chacun reste honnête sur sa propre perception.
Ce mécanisme s'appuie sur un phénomène bien documenté en psychologie sociale : l'effet d'ancrage. Le premier chiffre énoncé dans une discussion influence fortement les estimations suivantes. Le Planning Poker neutralise cet effet en supprimant la séquentialité.
Les désaccords sont de l'or. Une différence entre un 2 et un 13 signifie que l'équipe n'a pas la même compréhension du ticket. C'est exactement ce qu'on veut détecter avant de coder.
Les échelles d'estimation
Plusieurs échelles sont utilisées en Planning Poker :
Suite de Fibonacci modifiée (1, 2, 3, 5, 8, 13, 21) : la plus courante. Les écarts croissants reflètent l'incertitude grandissante sur les gros tickets. En savoir plus sur Fibonacci en agile.
Suite linéaire (1, 2, 3, 4, 5...) : plus intuitive mais problématique. Elle laisse croire qu'on peut distinguer un 7 d'un 8, alors que cette précision est illusoire sur des tickets complexes.
Puissances de 2 (1, 2, 4, 8, 16, 32) : utilisée par certaines équipes qui veulent des écarts encore plus marqués que Fibonacci. Moins courante, mais efficace pour forcer les décisions tranchées.
En plus des valeurs numériques, la plupart des jeux incluent des cartes spéciales :
- 0 : le ticket est trivial ou déja fait.
- ? (point d'interrogation) : "je n'ai pas assez d'informations pour estimer."
- Cafe : "on a besoin d'une pause."
Les variantes : au-dela du Planning Poker
Le Planning Poker n'est pas la seule technique d'estimation agile. Selon le contexte, d'autres approches peuvent être plus adaptées.
T-Shirt Sizing (XS, S, M, L, XL) : idéal pour les phases de cadrage ou quand l'équipe est peu familière avec les story points. Plus rapide, moins précis, parfait pour une roadmap trimestrielle. Voir notre article dédié sur le T-Shirt Sizing.
Dot Voting : chaque participant dispose d'un nombre limité de "points" (gommettes ou votes) a répartir sur les tickets. Ce n'est pas vraiment de l'estimation de complexité, mais plutôt un outil de priorisation. Utile quand l'équipe doit choisir quoi faire en premier, pas combien ça coûte.
Estimation par affinité (Affinity Mapping) : l'équipe trie les tickets en colonnes sur un tableau, du plus simple au plus complexe, sans attribuer de valeur numérique. On assigne les chiffres ensuite. Très efficace pour estimer un gros backlog d'un coup (30+ tickets en une heure).
Bucket System : une variante rapide ou les tickets sont "jetés" dans des seaux numérotés (0, 1, 2, 3, 5, 8, 13, 20+). Chaque participant prend un ticket et le place dans un seau. Les désaccords sont traités a la fin. Adapté aux très gros backlogs.
Les erreurs courantes en Planning Poker
Après des dizaines de sessions, certains pièges reviennent systématiquement :
1. Estimer en jours déguisés. "C'est un 5 parce que ça me prendra 5 jours." Non. Les story points mesurent la complexité relative, pas la durée. Si votre équipe pense en jours, les estimations seront faussées par les différences de niveau entre les membres.
2. Laisser le Product Owner voter. Le PO présente les stories, il ne les estime pas. Son vote peut involontairement influencer l'équipe ("si le PO dit 3, c'est que ça doit être rapide"). Le PO participe a la discussion mais ne montre pas de carte.
3. Viser le consensus a tout prix. L'objectif n'est pas que tout le monde soit d'accord. C'est que tout le monde ait la même compréhension du ticket. Si après deux tours de discussion l'écart se réduit de 2-13 a 5-8, c'est largement suffisant. Prenez la valeur médiane ou la plus haute et avancez.
4. Estimer trop de stories en une session. Au-dela de 60 a 90 minutes, la fatigue s'installe et la qualité des estimations chute. Mieux vaut planifier des sessions courtes et fréquentes que des marathons de 3 heures.
5. Ne pas avoir de story de référence. Sans point de comparaison, chaque estimation repart de zéro. Définissez une story de référence ("ce ticket de login qu'on a fait le mois dernier, c'est un 3") et comparez tout a elle.
6. Ignorer les cartes spéciales. Quand quelqu'un joue la carte "?", ce n'est pas de la paresse. C'est un signal que le ticket manque d'informations. Le pire serait de forcer une estimation sur un ticket flou.
Quand ne PAS utiliser le Planning Poker
Le Planning Poker n'est pas un outil universel. Il existe des situations ou d'autres approches sont plus efficaces :
Quand le backlog est énorme. Estimer 80 tickets en Planning Poker prendrait des heures. Pour un gros backlog initial, préférez le T-Shirt Sizing ou l'estimation par affinité, puis affinez en Planning Poker au fur et a mesure que les tickets approchent du sprint.
Quand les tickets sont tous similaires. Si votre équipe traite des tickets répétitifs et bien connus (corrections de bugs standardisées, intégrations d'API similaires), le Planning Poker apporte peu de valeur. L'équipe connait déja la complexité. Une estimation rapide par le tech lead suffit.
Quand l'équipe est très petite (2-3 personnes). Le Planning Poker tire sa force de la diversité des points de vue. Avec seulement deux développeurs, une discussion directe est plus naturelle et plus rapide.
Quand il n'y a pas de PO pour présenter les stories. Sans contexte métier, les estimations techniques pures manquent une partie de l'équation. Reportez la session plutôt que d'estimer a l'aveugle.
Retours d'expérience
"On a commencé par tout estimer, maintenant on est plus sélectifs." Beaucoup d'équipes démarrent en estimant chaque ticket, y compris les bugs mineurs et les tâches techniques. Avec le temps, la plupart se concentrent sur les stories significatives et laissent les petits tickets sans estimation. Le rapport effort/valeur est bien meilleur.
"Les plus gros gains viennent de la discussion, pas du chiffre." C'est le retour le plus fréquent. Le nombre sur la carte est presque secondaire. Ce qui compte, c'est le moment ou un développeur dit "attends, tu as pensé a la migration de la base ?" et ou tout le monde réalise que le ticket est deux fois plus gros que prévu.
"On a arrêté de discuter plus de deux tours." Certaines équipes limitent les discussions a deux tours maximum. Si le consensus n'est pas atteint, on prend la valeur la plus haute et on avance. Résultat : des sessions deux fois plus courtes sans perte de précision notable.
"Le remote a changé notre façon de jouer." Avec des équipes distribuées, les outils en ligne comme planning-poker.online ont remplacé les cartes physiques. L'avantage inattendu : l'historique des votes est conservé, ce qui permet d'analyser les patterns d'estimation au fil du temps.
Les outils pour jouer
- Cartes physiques : pour les équipes en présentiel. Rien ne vaut le plaisir de retourner une vraie carte sur la table. Vous pouvez acheter un jeu ou simplement imprimer les valeurs sur des post-its.
- planning-poker.online : notre outil en ligne gratuit, conçu pour les équipes remote. Créez une session en un clic, partagez le lien, et estimez en temps réel. Découvrez toutes les fonctionnalités disponibles : vote simultané, révélation synchronisée, historique des estimations.
- Extensions Jira : plusieurs plugins (Jira Planning Poker, Scrum Poker) s'intègrent directement dans votre backlog Jira.
Le meilleur outil, c'est celui que votre équipe utilisera vraiment. Un simple tour de table avec les doigts levés vaut mieux qu'un outil sophistiqué que personne n'ouvre.
