Le scrum poker dans une équipe Scrum

Dans beaucoup d’équipes Scrum, on dit « scrum poker » pour parler du planning poker. La mécanique ne change pas : cartes choisies en secret, retournement simultané, discussion sur les écarts. Elle est décrite avec un exemple complet dans notre guide du planning poker. Ici, on s’intéresse à ce que Scrum y change : le moment du sprint où l’on estime, la place du Scrum Master et du Product Owner, et l’usage des chiffres obtenus, en général des story points.

Pour rester concret, suivons une équipe de sept personnes chez un éditeur nantais de logiciel de gestion. Ses sprints durent deux semaines, et son chantier du trimestre consiste à connecter le produit à une plateforme de facturation électronique pour les clients B2B.

Le Scrum Guide et l’estimation

Ouvrez le Scrum Guide : les mots « story point », « vélocité » et « planning poker » n’y figurent pas. Le texte se contente de deux exigences. Les éléments du Product Backlog doivent être affinés jusqu’à tenir dans un sprint, et c’est aux Developers qui feront le travail d’en évaluer la taille.

D’où viennent alors les points et la vélocité ? Surtout des pratiques d’Extreme Programming, qui ont gagné les équipes Scrum au cours des années 2000, au point que beaucoup de gens les croient inscrites dans le cadre. Elles n’y sont pas. Des jours idéaux, des tailles de t-shirt ou l’absence totale de chiffres restent compatibles avec le Scrum Guide.

Pour notre équipe nantaise, ce constat a eu un effet pratique. Lors d’une rétrospective, deux développeurs se plaignaient de séances d’estimation interminables. Plutôt que de les subir comme une obligation, l’équipe s’est demandé ce qu’elle en retirait vraiment. Réponse : surtout les questions qui émergent quand les cartes divergent. Elle a gardé le vote et raccourci tout le reste.

Estimer pendant l’affinage ou pendant le Sprint Planning

L’affinage, le bon moment

L’affinage du backlog, que certaines équipes appellent encore « grooming » et d’autres « raffinement », consiste à préparer les éléments à venir : les clarifier, les découper, les estimer. Notre équipe y consacre une heure chaque mercredi de la première semaine du sprint.

L’avantage tient au décalage. Les stories estimées ce jour-là ne seront prises que dans un ou deux sprints. Quand une carte « 40 » apparaît sur « transmettre les factures au format Factur-X », il reste le temps de la découper. Quand une question porte sur les règles fiscales, la Product Owner peut interroger le service comptable avant le Sprint Planning plutôt que d’improviser une réponse.

Le Sprint Planning, pour ajuster

Au Sprint Planning, la question change : que peut-on livrer d’ici deux semaines ? Pour y répondre sans y passer la matinée, l’équipe a besoin de stories déjà chiffrées. Elle additionne, tient compte des congés de chacun, regarde les derniers sprints, puis ajoute ou retire un élément. Une story ne repasse au vote que si son contexte a bougé depuis l’affinage, par exemple quand le partenaire de facturation a changé son format d’échange entre-temps.

L’équipe nantaise a connu l’autre modèle, tout estimer le jour du Sprint Planning. Les réunions duraient une demi-journée et, vers la fin, les votes n’exprimaient plus qu’une envie d’aller déjeuner. Déplacer l’estimation vers l’affinage a ramené le Sprint Planning à une heure et demie.

Le Scrum Master anime, il ne vote pas

Chez l’éditeur nantais, le Scrum Master ne code pas : il n’a donc pas de carte en main, puisque l’estimation revient à ceux qui feront le travail. Il veille en revanche à la qualité du vote, à chaque étape de la séance.

• Avant le vote, il s’assure qu’aucune question n’est restée coincée. Un mercredi, son « vous voyez un cas qu’on n’a pas évoqué ? » a fait surgir la gestion des avoirs, que personne n’avait mentionnée.
• Pendant le vote, il ne défend qu’une règle : pas de chiffre à voix haute. Quand un développeur glisse « ça, c’est du 1 », il relance simplement un tour.
• Après la révélation, il fait parler d’abord les cartes qui s’éloignent du groupe. Comme il procède ainsi à chaque story, personne ne se sent pointé du doigt.
• Quand la discussion tourne en rond, il applique la règle de sortie décrite dans le guide du planning poker et note qui se charge de la question ouverte.

Il y a aussi ce qu’il doit éviter. Donner son propre avis sur le chiffre, même par une moue, pèse sur le vote suivant. Trancher à la place de l’équipe (« bon, on met 5 et on avance ») revient à retirer la décision aux Developers, alors que le Scrum Guide la leur confie. Et monopoliser la parole prive la séance de ce qui fait son intérêt : des développeurs qui s’expliquent mutuellement leur raisonnement.

Et le Product Owner ?

Dans la plupart des équipes, le Product Owner ne vote pas, puisqu’il ne réalisera pas le travail. Sa présence n’en est pas moins décisive. C’est lui qui lit la story, précise les critères d’acceptation et répond aux questions de fond : faut-il gérer les avoirs ? Les clients belges sont-ils concernés ?

Le piège, pour lui, est de commenter la taille. Une phrase comme « normalement c’est rapide » suffit à tirer les votes vers le bas ; ses remarques ont plus de valeur quand elles portent sur le besoin.

Les cartes « ? » et ☕

« ? » signifie qu’il manque une information pour estimer et ☕ que l’équipe a besoin d’une pause ; le Scrum Master prend l’une comme l’autre au sérieux. Leur usage est détaillé dans la section sur les cartes spéciales.

Ce que les points apportent au sprint

Dans un cadre Scrum, les points servent surtout à savoir combien l’équipe termine en général par sprint, pour ne pas surcharger le suivant : c’est la vélocité. Elle n’a de valeur que si l’échelle reste la même d’un sprint à l’autre. Le vote collectif y aide, parce qu’une valeur discutée par sept personnes dérive moins facilement que celle qu’un lead fixe seul, tard le soir, pour boucler le backlog. Le calcul et les idées reçues sur la vélocité sont traités dans la section vélocité et prévisions.

Quand on peut s’en passer

Une séance de scrum poker coûte au moins une heure par sprint à chaque membre de l’équipe. Certaines équipes ont de bonnes raisons de dépenser ce temps autrement.

Une équipe de support qui traite des tickets courts et comparables apprend autant en comptant les tickets fermés chaque semaine qu’en les chiffrant un par un. Un binôme qui maintient le même module depuis deux ans sait souvent d’un coup d’œil si une demande tient dans la semaine. En Kanban, le pilotage passe par le flux (temps de cycle, limites de travail en cours) et l’estimation de chaque carte n’y apporte pas grand-chose. Et si le Product Owner ne se sert jamais des chiffres, ni pour ordonner le backlog ni pour annoncer une date, la séance peut se réduire à une discussion sur le contenu des stories.

Le cas inverse existe aussi. Chez l’éditeur nantais, les sprints débordaient régulièrement avant que l’équipe se remette à estimer ensemble. Les votes ont montré, story après story, où se trouvaient les angles morts : presque toujours dans les échanges avec la plateforme de facturation, que seuls deux développeurs connaissaient vraiment.