Comment animer un Planning Poker étape par étape

Le Planning Poker fonctionne quand les cartes favorisent une conversation utile — pas quand l’équipe tente de deviner le « bon » chiffre. Une bonne séance offre à tous le même contexte du backlog, préserve le jugement indépendant jusqu’à la révélation, et utilise les écarts d’estimations pour faire émerger les hypothèses avant le sprint.

Ce guide vous propose un agenda réutilisable pour un facilitateur, un Product Owner ou responsable du backlog, et les personnes impliquées dans la réalisation du travail.

Dans ce guide

• La version courte
• Préparez le backlog et les participants
• Utilisez un agenda pratique de 45 minutes
• Calibrez et présentez chaque élément
• Votez, révélez, et discutez de la dispersion
• Revotez, divisez, ou faites une pause
• Revue de l’exemple à cinq items
• Évitez les erreurs courantes
• Utilisez la checklist du facilitateur

La version courte

Pour chaque élément du backlog :

1. Expliquez le résultat attendu par l’utilisateur, le périmètre et les critères d’acceptation.
2. Laissez l’équipe poser des questions de clarification.
3. Demandez à chaque estimateur de choisir une carte en privé.
4. Révélez toutes les cartes simultanément.
5. Si la dispersion est importante, écoutez les arguments des votes bas et hauts.
6. Clarifiez l’élément, divisez-le si nécessaire, puis revotez.
7. Enregistrez l’estimation validée par l’équipe, puis passez à l’élément suivant.

Le Planning Poker est une pratique d’estimation, non un événement Scrum obligatoire. Le Scrum Guide actuel laisse les méthodes de sizing à l’équipe, tout en soulignant que ce sont les personnes réalisant le travail qui sont responsables de la taille des éléments du Product Backlog.

Avant la séance : préparez des travaux discutables

Une salle de vote ne remplace pas un élément de backlog incompris. Préparez un petit ensemble d’items à court terme plutôt que d’amener tout le backlog.

Pour chaque élément, assurez-vous que l’équipe peut voir :

• le résultat utilisateur ou métier ;
• ce qui est inclus et explicitement exclu ;
• les critères d’acceptation ou un exemple de comportement attendu ;
• dépendances, contraintes et systèmes impactés connus ;
• questions ouvertes pouvant modifier la taille ;
• un lien vers des designs ou contexte technique pertinents.

Ne supprimez pas toutes les incertitudes avant l’estimation. L’incertitude fait partie de ce que l’estimation doit révéler. Mais l’équipe a besoin d’assez de contexte pour distinguer un détail d’implémentation mineur d’une décision produit non tranchée.

Choisissez une échelle avant le début du vote

Beaucoup d’équipes utilisent une séquence de type Fibonacci comme 1, 2, 3, 5, 8, 13, 21. Les écarts croissants reflètent que la confiance diminue généralement à mesure que le travail est plus grand ou moins compris. Agilo supporte aussi d’autres échelles par défaut et des jeux de cartes personnalisés.

Considérez les story points comme des tailles relatives propres à chaque équipe. Un 5 est utile parce que l’équipe comprend sa comparaison avec ses propres 2 ou 8 ; ce n’est pas une unité universelle d’heures et cela ne doit pas être reproduit entre équipes comme une table de conversion.

Invitez les bonnes personnes

Les personnes censées réaliser le travail doivent voter. Le Product Owner ou responsable du backlog explique l’intention, la priorité et les compromis. Un facilitateur fait avancer la séance, donne la parole aux plus discrets, et empêche que la discussion ne devienne une négociation en faveur d’un chiffre préféré.

Dans Agilo, les participants doivent avoir un compte pour rejoindre une salle et voter. Créez la salle avant la séance, sélectionnez le système d’estimation, ajoutez ou importez les premiers items, et partagez l’invitation suffisamment tôt pour que tous puissent se joindre.

Interface Agilo actuelle : huit participants fictifs ont voté, chaque estimation reste cachée jusqu’à la révélation.

Un agenda pratique de 45 minutes

Utilisez ceci comme point de départ, puis adaptez selon le nombre et la complexité des items.

Cinq items bien préparés sont souvent plus utiles que quinze votes précipités. Si l’équipe a régulièrement besoin d’une longue exploration produit en séance, reportez ces items en affinage et concentrez le Planning Poker sur du travail prêt à être dimensionné.

Étape 1 : calibrez avec un référentiel familier

Commencez par un item récemment terminé dont la forme est retenue par l’équipe. Il ne s’agit pas de réécrire l’histoire pour produire un score parfait. Vous donnez à la salle un point de comparaison commun : « Cet item comprenait une modification UI, une modification API, et une couverture test connue ; pour nous, il représente un 3. »

Utilisez des références issues de la même équipe et zone produit lorsque c’est possible. Le 5 d’une équipe mobile et celui d’une équipe plateforme n’ont pas à signifier la même chose.

Pour une échelle de référence concrète, comparez ces six exemples de story points, incluant les limites d’acceptation qui rendent un item plus petit ou plus grand.

Étape 2 : présentez un item du backlog

Le responsable du backlog expose en quelques minutes le résultat attendu et les limites. Évitez de détailler une implémentation proposée comme si elle était déjà décidée. Les développeurs peuvent envisager une solution plus simple — ou une dépendance qui modifie l’estimation globale.

Une introduction utile ressemble à ceci :

Un utilisateur connecté peut exporter le rapport actuel au format CSV. Ce tour inclut les filtres visibles du tableau, mais pas les exports planifiés ni le mappage de colonnes personnalisées.

Puis laissez l’équipe poser des questions. Si une question modifie le périmètre, actualisez l’item avant le vote.

Étape 3 : votez en privé puis révélez ensemble

Chaque estimateur choisit une carte sans voir les autres choix. Le vote caché limite l’ancrage sur le premier chiffre, la personne la plus senior, ou les attentes du facilitateur.

Révélez uniquement après que tous ont voté. Agilo peut dévoiler les cartes manuellement ou automatiquement dès que tous les participants ont voté, selon les paramètres de la salle. Un facilitateur peut aussi utiliser le minuteur de salle quand l’équipe doit respecter un cadre doux pour les questions ou votes.

Ne pressez pas ceux qui choisissent ?. Cette carte est une preuve utile : l’item peut manquer de contexte, être hors de son domaine d’expertise, ou contenir une hypothèse qu’il vaut mieux rendre visible.

Étape 4 : discutez de la dispersion, pas de chaque chiffre

Si les votes se regroupent autour de valeurs adjacentes, l’équipe peut se contenter d’une courte confirmation. Si la dispersion est large — par exemple, 3, 3, 5, 8, 13 — commencez par comprendre les raisons des estimations extrêmes.

Posez des questions comme :

• Que comprend le 13 que le 3 n’inclut pas ?
• Y a-t-il une dépendance ou un mode de défaillance que d’autres ont manqué ?
• Est-on en train d’estimer les mêmes critères d’acceptation ?
• Une personne suppose-t-elle une infrastructure réutilisable qui n’existe pas encore ?
• Diviser l’item supprimerait-il l’incertitude principale ?

Le but est une compréhension partagée. Le consensus peut suivre, mais forcer tout le monde vers une même carte sans résoudre la différence sous-jacente invalide l’exercice.

Quand une personne vote 3 et une autre vote 13 : bonne nouvelle — les cartes ne sont pas cassées. L’équipe vient de trouver la discussion qu’elle recherchait. 😅

Interface Agilo après révélation : la dispersion 3–8 incite à comparer les hypothèses. La moyenne 5,3 est un contexte, pas une réponse finale automatique.

Étape 5 : clarifiez, divisez, ou revotez

Après la discussion, choisissez l’une des trois options :

1. Revotez. L’item est clair et de nouvelles informations ont modifié la vision de l’équipe.
2. Divisez l’item. L’estimation est élevée car plusieurs résultats ou étapes techniques ont été regroupés.
3. Suspendez l’estimation. Une décision produit, une dépendance ou une investigation doit être résolue au préalable.

Agilo permet un nouveau tour de vote, mais ne choisit pas l'estimation finale pour l'équipe. Le facilitateur et les estimateurs décident toujours quelle valeur reflète leur compréhension commune.

Étape 6 : enregistrez le résultat et passez à l�27item suivant

Une fois que l’équipe s’est mise d’accord sur l’estimation à utiliser, enregistrez-la avec l’item du backlog et sélectionnez l’item suivant tant que la dynamique de la session est encore présente. Si vous utilisez l’intégration Agilo Jira, vous pouvez importer les tickets Jira avec leur contexte et renvoyer l’estimation sélectionnée lorsque la synchronisation est configurée.

Gardez une note séparée pour les questions à suivre. Ne dissimulez pas un périmètre incertain derrière un chiffre juste pour terminer la liste.

Exemple illustré : cinq items de backlog

Les valeurs ci-dessous appartiennent à une équipe produit fictive utilisant ses propres items de référence. Ce sont des exemples d’argumentation, non une clé universelle de réponses.

Considérez l’item des widgets. Les votants bas ont imaginé un changement de mise en page réservé au desktop. Les votants hauts ont inclus des gestes mobiles, l’ordre persistant, l’accessibilité clavier et la migration des mises en page existantes. Aucune moyenne ne pouvait résoudre ce décalage. Scinder l’item a rendu le périmètre explicite et a engendré deux conversations plus significatives.

Erreurs fréquentes qui affaiblissent la session

Considérer la moyenne comme la réponse

Une moyenne peut masquer deux interprétations incompatibles. Discutez d’abord de l’écart. L’estimation finale doit refléter le travail compris, non une commodité arithmétique.

Laisser la personne la plus senior voter à voix haute

Une fois qu’un chiffre est prononcé, les estimations suivantes gravitent autour. Gardez les cartes cachées jusqu’à la révélation et demandez les arguments après le vote indépendant.

Débattre de l’implémentation avant d’avoir une issue claire

La discussion technique est utile, mais uniquement après que tous comprennent ce que l’item doit accomplir. Sinon l’équipe peut estimer des produits différents.

Forcer une estimation pour un item non prêt

« Nous avons besoin d’un chiffre aujourd’hui » ne supprime pas une dépendance. Marquez la question, assignez un responsable et revenez-y quand la décision manquante est prise.

Comparer individus ou équipes par points d’histoire

Les points sont un outil local de planification. En faire un objectif de performance encourage des chiffres gonflés et rend les estimations moins utiles.

Liste de contrôle du facilitateur

Avant la réunion :

• choisissez 5 à 8 items à court terme ;
• ajoutez le contexte d’acceptation et les liens ;
• créez la salle et sélectionnez le jeu de cartes ;
• confirmez qui expliquera les items et qui votera ;
• choisissez un item de référence familier.

Pendant chaque tour :

• gardez les votes cachés jusqu’à ce que tout le monde soit prêt ;
• écoutez les arguments des votes bas et hauts lorsque l’écart compte ;
• mettez à jour l’item lorsque les hypothèses changent ;
• revotez, scindez ou mettez en pause plutôt que de forcer un accord ;
• enregistrez l’estimation sélectionnée et tout responsable pour un suivi.

Après la réunion :

• assurez-vous que les estimations sont visibles dans le backlog ;
• traitez les items en pause avant qu’ils n’atteignent la planification du sprint ;
• revisitez l’échelle seulement lorsque l’équipe la trouve systématiquement peu utile.

Exécutez le processus dans Agilo

Agilo Planning Poker conserve le contexte du backlog, le vote privé, la révélation simultanée, les tours répétés et l’estimation sélectionnée dans une même salle. Vous pouvez ajouter du travail manuellement ou importer des tickets Jira, utiliser un jeu de cartes intégré ou personnalisé et passer directement à l’item suivant après accord de l’équipe.

Créez une salle Planning Poker lorsque vos items de backlog et vos participants sont prêts.

Sources et lectures complémentaires

• Agile Alliance : Planning Poker — le modèle de vote privé, révélation simultanée, discussion et tours supplémentaires.
• Le guide officiel Scrum — la définition actuelle de Scrum et des responsabilités de dimensionnement du Product Backlog.