Le Planning Poker est une méthode d’estimation basée sur le consensus. Planning Poker est un outil utilisé par les équipes agiles du monde entier pour estimer leurs backlogs de produits. Les story points, les jours idéaux ou toute autre unité d’estimation peuvent être utilisés avec Planning Poker.
Qu’est-ce que Planning Poker et comment fonctionne-t-il ?
Planning Poker est une approche d’estimation et de planification agile basée sur le consensus. Le Product Owner ou le client lit une user story agile ou présente une fonctionnalité aux estimateurs pour commencer une session de planning poker.
Chaque estimateur a un jeu de cartes Planning Poker avec des valeurs telles que 0, 1, 2, 3, 5, 8, 13, 20, 40 et 100, ce qui est la séquence recommandée. Les chiffres indiquent la quantité estimée de points de conte, de jours idéaux ou d’autres unités par l’équipe.
Les estimateurs parlent de la fonctionnalité et posent des questions au Product Owner si nécessaire. Une fois que la fonctionnalité a été expliquée en détail, chaque estimateur choisit une carte pour représenter son estimation en privé. Ensuite, toutes les cartes sont révélées en même temps.
L’estimation est établie si tous les estimateurs ont choisi la même valeur. Si ce n’est pas le cas, les estimateurs débattent de leurs estimations. Les raisons des estimations hautes et basses doivent notamment être partagées. Chaque estimateur choisit à nouveau une carte d’estimation après un nouveau débat, et toutes les cartes sont exposées au même moment.
La procédure de planification au poker se poursuit jusqu’à ce que les estimateurs parviennent à un accord ou jusqu’à ce que les estimateurs déterminent que l’estimation et la planification agiles d’un élément spécifique doivent être reportées jusqu’à ce que des informations supplémentaires soient disponibles.
Quand peut-on utiliser le Planning Poker ?
Après la création d’un backlog de produit initial, la plupart des équipes organisent une session de Planning Poker. Cette session (qui peut durer plusieurs jours) sert à fournir des estimations préliminaires pour définir la portée et la taille du projet.
Parce que les éléments du backlog de produit (généralement sous la forme de user story) seront ajoutés au cours du projet, la plupart des équipes trouveront qu’il est bénéfique de faire des estimations agiles ultérieures et des réunions de planification une fois par itération. Comme toute l’équipe est présente à ce moment-là, cela se fait généralement quelques jours avant la conclusion de l’itération et peu après un standup quotidien.
Les étapes d’une séance de Planning Poker
Le Planning Poker rassemble les parties prenantes de plusieurs départements pour obtenir un accord sur le travail projeté nécessaire pour un certain nombre d’activités du backlog. Un Product Owner, des développeurs, des concepteurs UX, des testeurs QA et des Product Managers sont quelques-unes des parties prenantes dans une entreprise de logiciels agiles.
Exemple de démonstration d’un Poker de planification par ProductPlan
Étape 1 : Distribuez les cartes
Chaque participant reçoit un jeu de cartes (ou de jetons) identique avec un numéro différent sur chaque carte. Une séquence typique est 1, 2, 4, 8, 16, 32, 64, qui consiste à doubler chaque chiffre.
L’objectif étant que tous les joueurs obtiennent un chiffre consensuel pour chaque récit, les jeux de cartes sont restreints, avec des sauts de chiffres importants. Donner trop d’options aux participants – par exemple, chaque nombre de 1 à 50 – ralentirait le processus.
Étape 2 : Examinez les stories
Le Product Owner (ou éventuellement un Product Manager) lira ensuite chaque story au groupe à voix haute.
Étape 3 : Discuter
Le groupe débattra de la story maintenant que tout le monde l’a entendue. Les participants décriront comment ils prévoient de gérer le projet, y compris le nombre de personnes qu’ils prévoient d’engager, les compétences qui seront nécessaires et les obstacles potentiels. C’est également l’occasion pour le groupe de poser des questions sur le récit.
Étape 4 : Faites une estimation et partagez-la
Une fois que tout le monde s’est exprimé et qu’il a été répondu à toutes les questions, chaque participant choisit une carte du jeu de cartes pour symboliser son estimation des points de story. Lorsque tout le monde est prêt, chacun révèle sa carte simultanément.
Plus le chiffre inscrit sur la carte d’un participant est élevé, plus le récit est censé être difficile à réaliser.
Étape 5 : Faites un effort pour parvenir à un accord
Si tous les joueurs montrent la même carte, le consensus porte sur ce chiffre. Le groupe est maintenant prêt à passer au conte suivant.
Si les cartes sont différentes, le groupe continue à parler du conte. Ceux qui ont une estimation supérieure (ou inférieure) à celle du reste du groupe expliquent pourquoi et tentent de persuader leurs collègues d’être d’accord avec eux.
Une fois que le groupe a terminé ce nouveau tour de débat, chacun revoit ses cartes et choisit de maintenir son option précédente ou d’en faire une nouvelle. Au même moment, tous les participants dévoileront leurs cartes.
Est-ce que le Planning Poker est une méthode qui fonctionne ?
Absolument. Les équipes qui utilisent le Planning Poker affirment régulièrement que leurs estimations sont plus précises que toutes les autres méthodes qu’elles ont essayées.
Parce qu’il rassemble les points de vue de nombreux experts, le Planning Poker permet d’améliorer les estimations. Ces professionnels sont mieux adaptés que quiconque au travail d’estimation puisqu’ils constituent une équipe interfonctionnelle de toutes les disciplines d’un projet logiciel.
Magne Jrgensen, Ph.D., du Simula Research Lab, a déterminé après une évaluation approfondie de la littérature sur l’estimation des logiciels que « les personnes les plus compétentes pour accomplir le problème devraient l’estimer ».
Deuxièmement, pendant la planification du poker, il y a une discussion animée, et les estimateurs sont mis au défi par leurs pairs de défendre leurs estimations. Les chercheurs ont découvert que cette approche améliore la précision des estimations, en particulier pour les éléments présentant un degré élevé d’incertitude, comme la plupart des projets logiciels.
En outre, il a été prouvé que le fait de demander aux gens de défendre leurs prédictions produit des estimations qui compensent mieux les données manquantes. Dans le cadre d’un projet agile, cela est essentiel car les user stories à estimer sont souvent volontairement ambiguës.
Enfin, des études ont démontré que le calcul de la moyenne des estimations individuelles pendant l’estimation et la planification agiles, ainsi que les discussions de groupe sur les estimations, produisent des résultats supérieurs.
