Le Planning Poker est une technique d'estimation employée dans la méthodologie agile Scrum pour évaluer la taille ou l'effort requis pour des tâches de développement logiciel.
Basée sur une séquence de Fibonacci, elle promeut une discussion collective et un consensus d'équipe, en veillant à ce que chaque membre exprime son estimation sans être influencé par les autres.
Dans cet article, nous explorerons le fonctionnement de cette technique et le déroulement d'une séance de Planning Poker.
Qu'est-ce que le Planning Poker ?
Dans le cadre de l'approche agile, le "Planning Poker®" ou "Scrum Poker", une technique d'estimation souvent utilisé dans le cadre Scrum.
Contrairement à ce que son nom suggère, il n'est pas utilisé pour la planification mais pour l'estimation.
Malgré son nom plutôt aléatoire, c'est une technique fiable et précise.
Le Planning Poker Scrum a été créée en 2002 par James Grenning et popularisée par Mike Cohn dans son livre "Agile estimating and planning".
Ces deux contributeurs majeurs du manifeste agile ont ainsi donné vie à cet outil.
À première vue, une session de Planning Poker peut ressembler à un jeu de cartes ordinaire.
Les membres de l'équipe sont assis autour d'une table, chacun avec un jeu de cartes à la main.
Cependant, la similitude avec le Poker traditionnel s'arrête là.
L'usage de cartes vise à éviter l'influence mutuelle lors de l'estimation.
Chaque "joueur" pose sa carte simultanément avec les autres, évitant ainsi d'influencer les estimations des collègues en donnant son propre chiffre après avoir entendu celui d'un autre membre de l'équipe.
Vidéo tutorielle
Regardez cette vidéo pour comprendre le concept du planning poker, ses avantages et ses limites, le tout expliqué de manière illustrée :
A quoi sert un Planning Poker ?
Quand on gère un projet de manière agile, on doit évaluer des scénarios utilisateurs (user stories).
Mais combien de temps faut-il pour concrétiser/réaliser tel ou tel scénario ?
En particulier, comment faire des estimations fiables quand on n’a pas de références sur des projets similaires passés et/ou quand le scénario est complexe?
Le planning poker est l'une des pratiques populaires en la matière.
Qui participe au Planning Poker ?
Tous les membres de l'équipe de développement participent à la session de Planning Poker.
Voici les principaux participants :
- Le Product Owner : Il présente les User Stories aux autres participants et répond à leurs questions pour clarifier les exigences et les objectifs de chaque scénario.
- Les développeurs : Ils participent activement à l'estimation de la complexité des User Stories en fonction de leurs compétences techniques et de leur expérience.
- Le Scrum Master : Bien qu'il ne participe pas directement à l'estimation, le Scrum Master joue un rôle crucial en facilitant la session de Planning Poker. Il veille à ce que tout le monde comprenne le processus et contribue à la discussion.
- Les Testeurs : Si l'équipe inclut des testeurs, ils participent également à la session de Planning Poker. Leur perspective peut aider à identifier les défis potentiels en matière de testabilité qui pourraient influencer l'effort d'implémentation.
Modèle de la Matrice Fibonacci
Evaluez la charge pour réaliser votre produit
Dans certaines équipes, d'autres rôles peuvent également être invités à participer, comme les analystes d'affaires ou les concepteurs d'interface utilisateur, selon la nature des User Stories à estimer.
Cependant, il est essentiel de rappeler que le but du Planning Poker est de favoriser le consensus au sein de l'équipe de développement, en évitant l'influence externe qui pourrait biaiser l'estimation.
A quoi ressemblent les cartes du Planning Poker ?
Un jeu de cartes standard de Planning Poker agile est généralement conçu pour quatre "joueurs" ou estimateurs.
Si votre équipe est plus grande, il serait préférable d'avoir au moins deux jeux de cartes.
Chaque session inclut des cartes ayant des valeurs allant de 0 à 100, ainsi que deux cartes spéciales:
- Une marquée d'un point d'interrogation
- L'autre avec le symbole de l'infini
Les nombres sur les cartes représentent une progression non linéaire basée sur la suite de fibonacci agile, où chaque nombre est la somme des deux précédents.
C’est pourquoi on trouvera les chiffres suivants sur les cartes : 1, 2, 3, 5, 8, 13.
Toutefois, on trouvera ensuite les chiffres 20, 40 et 100 (au lieu de 21, 34 et 55).
Le symbole ∞ est utilisé quand l’estimateur pense que le scénario vaut plus de 100 unités et la carte avec le point d’interrogation est utilisée par l’estimateur ne sait pas estimer le scénario.
Il existe aussi des logiciels pour faire votre planning poker et des applications mobiles.
Astuce : Vous pouvez aussi imprimer votre planning poker vous-même.
Comment utiliser le Planning Poker pour estimer les User Stories ?
Le Planning Poker Scrum est un outil précieux utilisé lors des sessions de Sprint Planning dans le cadre de la méthodologie Agile.
Il facilite l'estimation de la complexité des User Stories.
Voici comment l'exploiter :
1. Attribution des points
La complexité des User Stories est évaluée en points, appelés "story points", plutôt qu'en jours-hommes.
2. Évaluation de la complexité relative
L'équipe Scrum compare ensuite les User Stories en fonction des points attribués à chacune.
Exemple :
Si une User Story se voit attribuer 3 points et qu'une autre en obtient 20, cela indique que la seconde est considérée comme étant environ sept fois plus complexe que la première.
3. Participation de tous les membres de l'équipe
Un des avantages majeurs du Planning Poker agile est qu'il donne à chaque membre de l'équipe l'opportunité d'exprimer librement son opinion.
Ce qui améliore la précision des estimations, car elles sont le fruit d'un consensus entre personnes ayant différents niveaux d'expérience et d'expertise.
4. Favoriser le dialogue
Enfin, cette méthode favorise les interactions et les échanges constructifs au sein de l'équipe projet, notamment entre le responsable produit et les développeurs.
Comment organiser un Planning Poker ?
Les membres de l'équipe agile se rassemblent autour d'une table, disposés de manière à pouvoir tous se voir, idéalement une table ronde.
Tous les membres de l'équipe de développement doivent être présents au minimum.
Dans le cadre de la méthode de gestion de projet DSDM Agile (Dynamic Systems Development Method), les participants devraient inclure le Business Analyst, le Team Leader, le Business Ambassador, les Solution Developers et les Solution Testers.
Voici comment se déroule une séance :
Etape 1 : Préparation des cartes et présentation du scénario utilisateur
Chaque participant reçoit un jeu de cartes du Planning Poker, chaque carte représentant une valeur d'estimation (souvent basée sur la séquence de Fibonacci pour refléter l'incertitude croissante avec la taille des tâches).
Le Product Owner (dans le cadre de Scrum) ou le Business Ambassador (dans le contexte de DSDM Agile) présente ensuite une User Story à tous les participants.
Il explique en détail ce que l'on attend du scénario, son objectif et son impact.
Etape 2 : Discussion sur le scénario utilisateur
Les participants échangent autour du scénario. Ils posent des questions au Business Ambassador ou au Product Owner pour clarifier les détails du scénario et comprendre précisément les conditions de réussite associées.
Cette étape peut engendrer des demandes d'éclaircissements ou des modifications du scénario.
Etape 3 : Estimation individuelle du scénario
Chaque participant réfléchit à la complexité du scénario en se basant sur son expérience et sa connaissance du projet.
Il sélectionne ensuite la carte correspondant à son estimation et la pose sur la table, face cachée, pour éviter d'influencer les autres participants.
Etape 4 : Révélation collective des estimations
Sur un signal du facilitateur, souvent le Scrum Master, toutes les cartes sont retournées simultanément.
Cela permet d'éviter les biais et assure que chaque estimation est indépendante et réfléchie.
Etape 5 : Discussion et consensus
Si toutes les estimations ne sont pas identiques, une discussion s'engage.
Les participants ayant proposé les estimations les plus basses et les plus élevées justifient leurs choix.
Après avoir entendu et compris ces points de vue, le groupe procède à une nouvelle estimation.
On répète cette étape jusqu'à ce que le groupe parvienne à un consensus.
Etape 6 : Définition de la valeur d'un "Story Point"
À la fin de la séance, l'équipe agile détermine la valeur temporelle d'un "Story Point", qui représente la quantité de travail que l'équipe est capable de réaliser pendant une itération (ou "sprint").
Cette valeur, souvent appelée "vélocité", permet de prévoir le travail qui peut être accompli lors des futurs sprints.
Ce processus de Planning Poker assure ainsi que chaque User Story est correctement évaluée et que chaque membre de l'équipe agile a la possibilité de contribuer à l'estimation.
Conclusion
En conclusion, le Planning Poker Scrum est une méthode précise et fiable d'estimation de la complexité des scénarios utilisateurs (ou user stories) dans le cadre de la gestion de projet Agile.
Cette technique, bien que ludique par son utilisation de cartes, a des principes sérieux qui facilitent la communication entre les membres de l'équipe et évitent l'influence mutuelle lors de l'estimation.
Les participants viennent d'horizons différents, possèdent des niveaux d'expérience et d'expertise variés, et peuvent ainsi enrichir l'estimation avec leurs perspectives uniques.
La mesure en Story Points agile et la détermination de la "vélocité" permettent de quantifier le travail que l'équipe de développement peut accomplir dans un laps de temps donné.
Enfin, le processus d'estimation peut être optimisé par la prise en compte des points de vue des participants ayant donné les estimations les plus élevées et les plus basses, ce qui facilite le consensus et améliore la précision de l'estimation.
Original, un côté ludique, permet aux personnalités moins affirmées de faire valoir leur point de vue. Mais ne pas multiplier ce « jeu » plusieurs fois avec la même équipe (risque d’ententes, de collusions, …)
Je pensais que c’était un jeu quand j’ai vu le titre, mais c’est un concept des plus originaux. Je pense que l’on peut en tirer pas mal d’avantages si l’on sait le mettre en place comme il se doit.