Introduction et contexte
Les demandes et les organisations des entreprises ne correspondent pas toujours à une agilité « by the book ». Pourtant, la volonté d’aller vers l’agilité est souvent sincère. En tant que coach agile, je dois composer avec ces contraintes, adapter mon accompagnement et faire avancer la transition dans un cadre organisationnel parfois rigide.
Contexte : mise en place de SAFe sur un pôle infrastructure comprenant 22 équipes Scrum ou Kanban, soit environ 150 personnes dans un ART.
Le Poker Planning est l’une des phases les plus importantes d’une démarche agile. Il permet d’estimer la charge d’un sprint et, par conséquent, la vélocité de l’équipe. Cette vélocité est un repère fondamental, car elle permet au Scrum Master de justifier objectivement une surcharge ou une impossibilité d’absorber de nouvelles demandes lors d’un Sprint Planning ou d’un PI Planning (SAFe). Elle doit donc être la plus juste possible afin d’être reconnue par les Product Owners et Program Managers.
La théorie agile stipule que chaque membre de l’équipe dispose d’un vote égal. Mais selon le contexte dans lequel on pratique l’agilité, ce principe ne répond pas toujours aux besoins. Par exemple : équipe multi-produits, équipe mêlant Build et Run, ou encore équipe composée de compétences très diverses (développeurs, experts réseau, graphistes, etc.). Dans ces cas-là, il faut savoir adapter l’interprétation des votes.
Outils
L’objectif est de gérer efficacement la diversité des propositions, tout en évitant des discussions trop longues — car ces discussions sont le point le plus chronophage d’un Poker Planning.
Je recommande d’utiliser les cartes de la suite fibonacci suivantes : 1, 2, 3, 5, 8, 13 et 21.
Les cartes que je recommande d’utiliser incluent deux ajouts :
« ? » : l’équipier n’a pas assez d’informations pour voter.
« NSP » : l’équipier n’est pas concerné par l’US et n’a aucun avis.
Remarque : même un équipier peu concerné peut voter s’il a une idée de la charge. Je l’y encourage.
Postulats de départ
Les US et tâches ont déjà été présentées en amont lors d’un PBR (Product Backlog Refinement). L’équipe les connaît déjà.
Remarque : présenter une US en détail puis voter immédiatement dans la même réunion est selon moi une mauvaise pratique. Les équipiers ont besoin d’un temps de réflexion ; les mettre devant un vote immédiat génère du stress. Un simple rappel avant le vote suffit.
Le Poker Planning est expliqué à l’équipe.
Il faut insister sur le fait qu’on estime une charge et non un temps passé. Pour les premières estimations, j’envoie un tableau d’aide décisionnelle afin d’aider les équipiers à se situer.
La vélocité est expliquée pour rassurer l’équipe.
Je montre des burndown fictifs et j’explique que l’objectif est de protéger l’équipe :
- contre les demandes “à la volée”,
- contre les changements de scope en cours de sprint,
- contre les pressions de deadline.
Une fois la vélocité stabilisée, les vrais dysfonctionnements apparaissent (staffing, manque de compétences, etc.).
Le Scrum Master anime et garantit le cadre.
Il énonce les US une par une. Les votes sont dévoilés simultanément. Le PO apporte de l’information mais ne vote pas et ne commente pas les votes. Le Scrum Master rappelle que chaque estimation, même subjective, est légitime.
Interprétation des votes
Lexique : un échelon représente l’écart entre deux valeurs (ex : entre 2 et 5 il y a deux échelons).
Objectif : savoir à quel moment une discussion est nécessaire.
Règles : L’unanimité n’est pas un objectif. Pas de discussion si les votes sont proches.
Si un équipier veut défendre sa note, il peut l’expliquer. Si son argument convainc, sa note peut être pondérée plus fortement (x2). Même s’il ne convainc pas, sa note peut être réévaluée à la hausse. Si un autre équipier défend l’opposé, on ouvre une discussion jusqu’à ce que l’un des deux revoie son estimation.
La note de la personne qui réalisera l’US peut être pondérée plus fortement (x2).
Si tout le monde a la même note : on valide immédiatement.
En cas d’égalité : on retient la valeur la plus élevée.
S’il n’y a qu’un échelon d’écart : on retient la majorité, après une brève discussion. Exception : si le futur réalisateur a voté la valeur la plus haute, on prend celle-ci.
Si l’écart dépasse deux échelons : seuls les extrêmes discutent entre eux. S’il n’y a pas d’accord, on retient la valeur la plus élevée.
Si les votes sont totalement dispersés : le Scrum Master demande au PO de redéfinir clairement le scope. L’US peut repartir en refinement. En attendant, on l’estime à un niveau très élevé (ex : 21).
Le Scrum Master doit écouter, cadrer, limiter la durée des échanges, et évaluer si les arguments apportent réellement de la valeur.
Conclusion
Je ne couvre pas ici tous les cas particuliers possibles, mais ces huit règles permettent de traiter environ 90 % des situations. Beaucoup d’équipes vivent le Poker Planning comme une perte de temps, surtout lorsqu’elles débutent en agilité. L’objectif est donc de le rendre aussi court et utile que possible, tout en conservant sa valeur et son rôle dans la conduite du changement.
