Le planning poker, mode d'emploi

Le planning poker, qu’on appelle parfois poker de planification, est une technique d’estimation agile fondée sur le vote simultané. Chaque membre de l’équipe a les mêmes cartes numérotées. On lit une user story, on en discute juste assez pour la comprendre, puis tout le monde abat sa carte au même moment. Si les valeurs sont éloignées, ceux qui ont voté le plus haut et le plus bas prennent la parole, et l’équipe revote.

Tout le reste découle de ce geste. Chacun a arrêté son chiffre avant de connaître celui des autres, si bien que les désaccords apparaissent au grand jour au lieu de se dissoudre dans le premier avis exprimé. Ce sont ces désaccords, et les explications qu’ils déclenchent, qui font la valeur d’une séance.

Aux origines de la méthode

Le planning poker descend de la méthode Delphi, mise au point à la RAND Corporation dans les années 1950 et 1960. Un groupe d’experts y répond de façon anonyme, reçoit une synthèse des réponses du groupe, puis révise son avis sur plusieurs tours. Dans les années 1970, Barry Boehm et John Farquhar l’ont adaptée à l’estimation logicielle sous le nom de Wideband Delphi, en ajoutant des échanges entre les tours.

En 2002, James Grenning a décrit dans un court article une version beaucoup plus légère, pensée pour que la planification des releases ne s’éternise pas. Son jeu d’origine comptait les cartes 1, 2, 3, 5, 7, 10 et ∞. Mike Cohn a ensuite consacré à la technique une section du chapitre sur les méthodes d’estimation de son livre Agile Estimating and Planning (2005), et ce livre a beaucoup contribué à la diffuser dans les équipes Scrum et XP. Aujourd’hui, la plupart des équipes s’en servent pour attribuer des story points aux éléments du backlog.

Déroulement d’un tour

1. Distribuer le jeu. Le plus répandu est une suite de Fibonacci modifiée : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, avec en plus « ? » et une tasse de café. Les écarts grandissent avec les valeurs, et la page sur la suite de Fibonacci explique pourquoi.
2. Présenter la story. Le Product Owner décrit le besoin de l’utilisateur et les critères d’acceptation.
3. Poser les questions. L’objectif est de pouvoir estimer, pas de concevoir la solution en séance.
4. Choisir sa carte en silence. Pas de « moi je partirais sur un petit truc ».
5. Retourner toutes les cartes ensemble.
6. Si les votes sont proches, on s’accorde en quelques secondes. Avec 2, 3, 3 et 3, l’équipe retient généralement 3.
7. S’ils sont éloignés, les votes extrêmes s’expliquent en premier, puis on refait un tour.

Qui a droit à une carte ? Ceux qui construiront la fonctionnalité : développeurs, testeurs, parfois la personne chargée de l’exploitation. Le Product Owner connaît le besoin mieux que quiconque, mais pas l’effort ; dans la plupart des équipes, il reste du côté des réponses. Quant au responsable venu « juste écouter », sa carte pèserait plus lourd que les autres, et il rend service à tout le monde en restant spectateur.

Exemple : un 3, un 13 et une histoire de données de santé

Une équipe qui développe l’appli d’une mutuelle en est à la cinquième story de la séance : « En tant qu’adhérent, je veux photographier ma facture d’opticien depuis l’appli pour demander mon remboursement. »

Les cartes se retournent : 3, 5, 8, 13. Julien a posé le 3, Camille le 13. Comme à chaque écart, Nadia, la Scrum Master, leur donne la parole avant les autres.

Julien est optimiste : le composant d’envoi de justificatifs existe déjà pour l’adhésion, il suffit de le brancher sur le formulaire de remboursement. C’est justement ce point qui inquiète Camille. Les justificatifs d’adhésion, rappelle-t-elle, sont stockés sur l’hébergement habituel de l’entreprise. Une facture d’opticien est une donnée de santé ; elle doit aller chez un hébergeur certifié HDS, avec ses propres accès et son propre chiffrement.

Sofiane, qui avait posé 8, ajoute un autre souci : les iPhone envoient des photos en HEIC, un format que le back-office des gestionnaires ne sait pas afficher, et il faudra les convertir.

La Product Owner, qui participe à distance, écrit au service conformité pendant la discussion. La réponse arrive avant la fin de la séance : aucune pièce médicale hors de l’hébergement certifié.

L’équipe ne revote pas la story entière. Elle la coupe en deux, la conversion HEIC d’un côté, l’envoi vers l’hébergement certifié de l’autre, et vote chaque partie : 3 pour la première, 8 pour la seconde. Dans le ticket, Camille ajoute une ligne sur la contrainte HDS, pour que la revue de sécurité la trouve écrite noir sur blanc plutôt que de la découvrir.

Les erreurs classiques

Laisser filer un chiffre avant le vote

« On est d’accord que c’est pas énorme ? » Posée avant le vote, la question fixe un repère, et les cartes qui suivent s’en écartent peu. C’est l’ancrage. Le Product Owner lance souvent ce genre de phrase par gentillesse, pour rassurer l’équipe sur la simplicité du besoin. La parade tient en une règle : aucun commentaire sur la taille avant le retournement, pas même de sa part.

S’aligner sur l’architecte

Une développeuse arrivée il y a trois mois pense 13 ; l’architecte, lui, vient de dire qu’il hésitait entre 3 et 5. Au second tour, bien des juniors finissent par rejoindre la carte du senior. Pour que ce 13 soit entendu, l’animateur distribue la parole en fonction des cartes, pas des personnes : on commence par celles qui s’écartent du groupe. L’exemple de la mutuelle le montre : c’est le 13 de Camille, entendu en premier, qui a fait apparaître la contrainte HDS.

Chiffrer une story trop floue

Les questions tombent et personne ne peut répondre : le Product Owner ne sait pas si l’offre concerne aussi les ayants droit, l’expert métier est en congé. Voter quand même donne un chiffre qui ne repose sur rien. « ? » est alors la carte la plus honnête, et la story attend la réponse pour repasser à la séance suivante. La suite à donner est décrite dans la section sur les cartes spéciales.

Calculer une moyenne pour conclure

La salle affiche 1, 2 et 20. Le réflexe arithmétique donne un peu moins de 8, une valeur que personne n’a jouée. L’écart, lui, dit quelque chose de précis : soit la personne au 20 voit un chantier que les autres n’imaginent pas, soit les deux autres connaissent un raccourci qu’elle ignore. Tant qu’on ne sait pas laquelle des deux lectures est la bonne, la moyenne n’apprend rien.

Transformer la séance en atelier de conception

À force de questions, on glisse vers la conception : schémas au tableau, comparaison de deux bibliothèques, et la troisième story n’a toujours pas été votée. Fixez une limite. Si deux tours n’ont pas rapproché les cartes, on arrête de voter sur cette story et on choisit entre trois issues : la découper, la reporter en confiant la question ouverte à quelqu’un, ou retenir provisoirement la carte la plus haute.

Animer un planning poker à distance

Recopier les votes dans le chat de la visio paraît pratique. Mais les messages arrivent les uns après les autres, et ceux qui tapent en dernier ont lu les premiers avant d’envoyer le leur : l’ancrage revient par la petite porte. Une salle de vote dédiée garde chaque carte cachée jusqu’à ce que l’équipe les retourne ensemble.

La préparation compte davantage qu’en présentiel. La veille, l’animateur envoie la liste des stories. Si l’équipe est éclatée entre Montréal et Lyon, la plage horaire commune fait à peine trois heures, et on ne la gaspille pas en lecture. Le jour venu, il ouvre une salle de planning poker en ligne, colle le lien dans le chat de Teams ou de Zoom et partage le ticket à l’écran. Les votes arrivent un à un ; la salle montre qui a choisi, sans dire quoi. Une fois les cartes retournées, la discussion se fait au micro plutôt que par écrit, parce qu’un échange oral règle en une minute ce qu’un fil de messages étire sur dix. SprintPoker fonctionne ainsi, sans inscription ; la page À propos précise ce que l’outil fait et ne fait pas.

Planning poker et Scrum

La technique ne dépend d’aucun cadre, mais la plupart des équipes qui l’utilisent travaillent en Scrum. Où placer l’estimation entre l’affinage du backlog et le Sprint Planning, et quel rôle y joue le Scrum Master : c’est l’objet de la page Scrum poker.