Règles du Planning Poker : un accord pour votre équipe
Qui estime, quand retourner les cartes et comment traiter une question sans réponse ? Des règles concrètes, illustrées par une conversation d’équipe.
Les règles de base du Planning Poker sont d’estimer le même périmètre, de choisir les cartes individuellement, de les révéler ensemble et de comprendre les écarts avant de retenir une estimation. Convenez aussi des personnes qui votent et des situations où il faut une réponse plutôt qu’un chiffre.
« C’est un deux, non ? » Une phrase suffit à orienter le prochain vote. La personne qui pensait à un huit doit maintenant défendre son idée avant même de montrer sa carte. Quelques règles partagées permettent à chacun de réfléchir d’abord.
Le choix individuel et la révélation commune font partie de la pratique décrite par Agile Alliance. Les réponses aux exceptions ci-dessous sont des propositions à adapter. Pour préparer la séance et son déroulement, consultez le guide pas à pas du Planning Poker.
Dans ce guide
Quand les votes cachent des exigences différentes
Une équipe fictive estime : « Permettre à un administrateur d’annuler une invitation à l’espace de travail qui n’a pas encore été acceptée. » Les cartes sont 2, 2, 5 et ?.
Une personne ayant choisi
2: « On rend simplement l’invitation existante invalide. »La personne ayant choisi
5: « Et si elle est acceptée exactement au même moment ? »La personne ayant choisi
?: « Si elle a déjà été acceptée, faut-il retirer le membre ? »
Retenir le chiffre majoritaire laisserait ces questions ouvertes. La personne qui facilite demande au Product Owner de distinguer le retrait d’une invitation en attente de la suppression d’un membre existant. Ce dernier cas devient une autre exigence. Il reste à décider ce qui se passe si acceptation et annulation sont simultanées.
Le tour se termine avec une question et une personne chargée de la clarifier. Une fois la décision notée, l’équipe pourra estimer le périmètre précisé. Aucun chiffre définitif n’est encore nécessaire.
Un vote compare la compréhension du travail ; il ne définit pas le comportement du produit. Les chiffres servent uniquement à cet exemple, pas à dimensionner toute fonction d’invitation.
Les règles à fixer avant le vote
| Règle | Application concrète |
|---|---|
| Estimer un périmètre commun | Rendre visibles le comportement attendu et ses limites. Les anciens votes portent sur l’ancien périmètre. |
| Choisir une unité et un jeu de cartes | Story points ou autre unité : ne pas mélanger heures et taille relative dans le même vote. |
| Faire estimer les personnes qui réalisent le travail | Inclure les compétences nécessaires pour terminer, sans donner plus de poids à un titre ou à l’ancienneté. |
| Choisir individuellement, révéler ensemble | Ne pas suggérer de chiffre cible ni révéler pendant que quelqu’un choisit encore. |
| Explorer les hypothèses derrière les cartes | Écouter les estimations basses, hautes et les autres objections. Une minorité peut avoir repéré du travail oublié. |
| Distinguer les signaux non numériques | Une question, le fait de passer son tour et une demande de pause ne sont pas des estimations chiffrées. |
| Savoir conclure ou s’arrêter | Retenir un chiffre utilisable par l’équipe ou noter la question à résoudre d’abord. |
| Réestimer pour une information nouvelle | Un changement de périmètre le justifie ; un total souhaité dans un rapport ne change pas le travail. |
Pour les story points, utilisez des éléments terminés comme références. Les exemples de story points montrent comment préciser leurs limites ; le guide de Fibonacci explique les échelles. Ces règles n’imposent ni jeu particulier ni conversion fixe en heures.
Qui estime et qui facilite
Selon le Scrum Guide, section Product Backlog, les Developers qui réalisent le travail en déterminent la taille. Il s’agit des personnes qui créent un Incrément utilisable, avec des compétences qui vont au-delà de la programmation. Scrum n’impose ni Planning Poker ni ses règles d’exception.
Une personne chargée des tests peut demander : « Que se passe-t-il si l’administrateur perd ses droits pendant l’opération ? » Cette question fait partie de l’estimation de l’élément complet. Ce n’est pas une estimation QA distincte à additionner aux points du frontend et du backend.
Le Product Owner explique le résultat et aide à définir ce qui est inclus. La personne qui facilite veille à ce que personne ne dicte le chiffre attendu. Aucun de ces rôles ne donne de voix supplémentaire. Si une personne contribue aussi à la réalisation, précisez à quel titre elle estime. Mountain Goat Software décrit cette distinction.
Avant de révéler, identifiez les personnes qui estiment cet élément. Un observateur n’a pas à donner un chiffre uniquement pour compléter la liste des votes.
Quand un tour ne se passe pas comme prévu
Quelqu’un choisit un point d’interrogation ou passe
« J’ai choisi ? parce que je ne sais pas si les anciennes invitations doivent rester valides. » Voilà une question précise. Cherchez le contexte manquant au lieu d’écarter discrètement cette carte.
?: j’ai besoin d’une réponse avant d’estimer.- Passer : je ne donne pas d’estimation pour cet élément.
0, si la carte existe : une estimation numérique dont l’équipe a défini le sens.
Passer ne signifie ni zéro ni accord silencieux. Si cela révèle un manque de connaissances essentielles, notez-le. La carte de pause est une demande distincte.
Une personne nécessaire est absente
« Notre spécialiste des bases de données a perdu la connexion. Peut-on continuer ? » Si l’équipe comprend ce travail, oui. Si sa réponse peut changer la solution, notez la question et reportez l’estimation. Son absence ne vaut pas accord.
Un chiffre est annoncé trop tôt
« C’est forcément un deux. » Faites une pause et revenez au périmètre. Chacun reconsidère son choix individuellement ; si les cartes sont ouvertes, lancez un autre tour. Recommencer ne fait pas oublier le chiffre : invitez explicitement les avis différents.
L’exigence change après le vote
« Il faut aussi retirer les invitations envoyées le mois dernier. » Cette précision constitue une nouvelle information. Mettez à jour les critères d’acceptation avant d’estimer à nouveau. Le résultat précédent concernait le périmètre précédent.
Les votes divergent encore ou quelqu’un veut un chiffre inférieur
Encore des cinq et des huit ? Demandez : « Quel travail avez-vous inclus que les autres ont peut-être oublié ? » Si le périmètre est identique, revenez aux références. Si les exigences diffèrent, clarifiez-les d’abord.
Capture Agilo existante, avec des participants fictifs et une interface en anglais. La moyenne de 5,3 n’explique pas les écarts. Revote permet un nouveau tour ; l’équipe décide si une clarification ou une autre action doit le précéder.
« Il nous le faut cette semaine, vous pouvez mettre trois ? » C’est une question de périmètre et de priorités. Discutez de ce qui peut être retiré ou changé. Une carte plus basse ne supprime aucun travail.
Agile Alliance met en garde contre la convergence forcée. L’équipe peut adopter une estimation sans que chacun préfère personnellement la même carte. Écoutez les réserves et arrêtez-vous si le chiffre masquerait une exigence non résolue. Ni la moyenne ni l’avis de la personne la plus expérimentée ne la tranchent.
Un accord d’équipe à reprendre
Ajoutez ce texte à vos notes et remplissez les crochets. Il doit rester assez court pour être lu avant le premier vote. Ce sont des accords d’équipe, pas des réglages imposés automatiquement par l’outil.
Jeu et unité : [choisir]. Références : [lien].
Personnes qui estiment cet élément : [noms/compétences].
Facilitation : [nom]. Questions produit : [responsable].
Clarifier le périmètre, choisir individuellement, révéler ensemble.
Ne pas annoncer de chiffre cible avant la révélation.
Écouter les raisons des écarts et les réserves restantes.
? signifie une question ; passer n’est ni zéro ni un accord.
Limite de discussion : [durée ou condition d’arrêt].
Nouveau périmètre : exigences mises à jour et nouvelle estimation.
Retenir un chiffre lorsque les personnes qui estiment peuvent l’utiliser.
Contexte ou expertise manquants : question → responsable → prochaine étape.
Réestimer pour une nouvelle information, pas pour un total souhaité.
La limite de discussion aide à choisir la suite, pas à imposer l’unanimité à une heure donnée. Revoyez l’accord s’il empêche la participation ou dissimule l’incertitude.
Utiliser cet accord dans Agilo
Gardez l’accord dans les notes de l’équipe et votez avec Agilo Planning Poker. Choisissez le jeu convenu, masquez les choix jusqu’à la révélation et relancez un tour quand le périmètre change. Les systèmes intégrés proposent un point d’interrogation, une carte de pause et la possibilité de passer ; l’équipe définit la réponse à ces signaux.
Créez une salle de Planning Poker lorsque participants, périmètre et règles sont clairs. Pour le déroulement complet, revenez au guide de facilitation.
Sources
- Agile Alliance : Planning Poker — pratique et risque de convergence forcée.
- Scrum Guide officiel — responsabilité du dimensionnement, sans imposer Planning Poker.
- Mountain Goat Software : Planning Poker — participation et cartes non numériques.
