Facilitateur, pas décideur
Pendant le Planning Poker, le Scrum Master a un rôle bien défini : faciliter le processus d'estimation sans l'influencer. Il ne donne pas son avis sur la complexité des stories et ne vote généralement pas — sauf s'il contribue aussi au développement.
Son objectif : créer les conditions pour que l'équipe arrive à un consensus éclairé, dans un temps raisonnable, en s'assurant que chaque voix est entendue.
Avant la session : la préparation
- 1
Vérifier le backlog avec le PO
S'assurer que les stories sont suffisamment affinées : critères d'acceptation clairs, maquettes disponibles, dépendances identifiées. Une story floue = 15 minutes de débat inutile.
- 2
Préparer l'outil
Créer la session sur PokerPlanning.fr, choisir le jeu de cartes adapté (Fibonacci, T-Shirt ou Puissances de 2) et ajouter les stories à estimer.
- 3
Définir le timebox
Prévoir 1-2 minutes par story en moyenne. Pour 15 stories, bloquez 30-45 minutes. Communiquez le créneau à l'équipe à l'avance.
Pendant la session : les 6 missions du SM
Garder le rythme
Timeboxer chaque story (2-5 min max). Si le consensus ne vient pas après 2 tours de vote, proposer de reporter la story au prochain refinement.
Donner la parole
Après révélation des votes, demander systématiquement au vote le plus haut ET le plus bas d'expliquer leur raisonnement. Les extrêmes ont souvent vu quelque chose que les autres ont manqué.
Protéger contre le biais d'ancrage
S'assurer que tous les votes sont révélés simultanément. Empêcher quiconque de dire « moi je mettrais un 5 » avant le vote — c'est le principe même du Planning Poker.
Faciliter le consensus
Si les votes divergent (ex : 3 et 13), guider la discussion sans prendre parti. Poser des questions : « Qu'est-ce que tu as vu que les autres n'ont pas vu ? »
Capturer les hypothèses
Quand un consensus repose sur une hypothèse (« si l'API existe déjà »), la noter. Si l'hypothèse s'avère fausse, l'estimation devra être revue.
Éviter les dérives
Couper les discussions techniques trop détaillées (architecture, choix d'implémentation). L'estimation porte sur la complexité, pas sur la solution technique.
Les erreurs à ne pas commettre
Voter avec l'équipe
Si le SM vote, il influence inconsciemment l'équipe — surtout s'il a une position hiérarchique. Exception : si le SM est aussi développeur dans une petite équipe.
Imposer un consensus
« Allez, on met 5 et on passe à la suite » — c'est le meilleur moyen d'obtenir des estimations qui ne reflètent pas la réalité. Le consensus doit être organique.
Utiliser les estimations contre l'équipe
Jamais de « vous aviez dit 5 points, pourquoi ça a pris 3 jours ? ». Les Story Points mesurent la complexité relative, pas le temps. Le SM protège cette distinction.
Après la session
Le travail du Scrum Master ne s'arrête pas quand la session se termine. Voici ce qu'il doit faire ensuite :
- Reporter les estimations dans l'outil de gestion (Jira, Linear, Trello…) si ce n'est pas automatique.
- Suivre la vélocité — comparer les estimations avec les livraisons réelles pour calibrer la vélocité de l'équipe.
- Identifier les patterns — certaines stories sont systématiquement sous-estimées ? C'est un signal pour la rétrospective.
- Améliorer le processus — raccourcir les sessions trop longues, ajouter du refinement si les stories arrivent mal préparées.
Facilitez votre prochaine session
PokerPlanning.fr gère le vote simultané, la révélation et le consensus — vous n'avez plus qu'à faciliter.
Créer une session gratuite