Accueil > Vers l'Agilité > Planning Poker

Planning Poker

Qu'est-ce que le planning poker?

L'équipe de développement logiciel fait du planning poker pour produire des estimations de la complexité des fonctionnalités à développer. Les estimations fourniront aux responsables de produit (product owners ou PO) des outils pour la planification et la priorisation des fonctionnalités à développer.

L'essence de cet exercice est de permettre à toute l'équipe de s'exprimer sur l'effort requis, en minimisant l'influence des autres membres de l'équipe.

Comment?

1. Chacun des participants reçoit un paquet de cartes.
2. Le responsable de produit lit un scénario utilisateur (user story) et en discute avec l'équipe brièvement.
3. Chacun des participants mesure en silence la complexité de ce scénario, choisit la carte qui correspond à son estimation et dépose la carte, face vers le bas, sur la table devant lui.
4. Lorsque tous les participants ont fait leur estimation, les cartes sont retournées en même temps de façon à ce que tout le monde puisse les voir.
5. S'il n'y a pas unanimité, une discussion est entamée. Une compréhension différente du besoin ou de la solution à adopter peut être la cause des divergences d'opinion.
6. On répète le processus d'estimation jusqu'à l'obtention de l'unanimité.

Références

• www.crisp.se/planningpoker/
• www.planningpoker.com/ – Jouez en ligne! outil pratique pour les équipes distribuées.
• fr.wikipedia.org/wiki/Planning_poker

Recommandations pour le facilitateur

• Assurez-vous que la définition de 'Done' soit bien comprise par tous.
• Assurez-vous que tous les participants savent qu'ils doivent évaluer la complexité de la fonctionnalité au complet. Certains auront tendance à évaluer seulement "leur" partie.
• Portez attention aux communications non verbales. Certains voudront contourner l'interdiction de parler en utilisant un langage non verbal très fort. D'autres auront tendance à bluffer. Ni l'un ni l'autre ne devrait être encouragé.
• Portez attention aux discussions qui s'éternisent : il y a un point où discuter davantage ne permet plus d'avoir une estimation plus juste. Restreindre les discussions à une durée fixe (time box) de quelques minutes permet d'être efficace.
• Portez attention aux équivalences en 'jours-personnes'. Il est important que chacun garde ses équivalences pour lui. Le fait d'utiliser des points permet de se concentrer sur la complexité relative des scénarios utilisateurs, et non sur leur durée réelle.

Foire aux questions

Comment débute-t-on?

La première étape est de trouver l'étalon. Il faut chercher une fonctionnalité qui servira de point de comparaison pour toutes les autres.

Une fois qu'on a trouvé l'étalon, il faut quand même discuter du périmètre de ce scénario utilisateur pour que la compréhension de l'étalon soit réellement commune. Au besoin, on peut demander à l'équipe de découper ce scénario en tâches. Ensuite, il faut s'assurer que l'échelle n'est pas trop grande. Des points de 5 jours et plus deviennent des handicaps plus tard dans le projet.

Ne démarrez pas avec un étalon '1', vous vous retrouverez rapidement avec des '1/2' et vous voudrez ajouter un '1/4' à votre échelle... Nous vous conseillons d'utiliser un étalon qui a une valeur de '3'. Pour trouver le scénario idéal, cherchez-en un petit, et trouvez-en un autre qui est environ deux fois plus gros.

Peut-on changer l'échelle de référence en cours de séance?

Ce n'est pas recommandé. Chacune des valeurs de l'échelle a une connotation bien précise pour les participants; changer cette échelle peut créer beaucoup de confusion.

En cours de projet, ce n'est pas idéal non plus.

Comment puis-je améliorer la compréhension commune de l'échelle de valeurs utilisée?

Sur le babillard ou le tableau blanc où l'échelle est inscrite, affichez les cartes des scénarios estimés dans la bonne colonne.

Doit-on estimer les gros scénarios utilisateurs (epics) avec la même échelle?

Estimer les gros scénarios utilisateurs avec la même échelle est une bonne pratique (8, 13, 20, 40...). Cela permet de ne pas avoir à faire de distinction réelle entre les scénarios de tailles diverses. Toutefois, dans de nombreux cas, les équipes ne ressentent pas le besoin d'estimer ces grands ensembles de fonctionnalités. Après tout, ils seront réestimés quand ils seront découpés.

Le total des points alloués aux scénarios qui résultent du découpage d'un gros scénario doit-il nécessairement totaliser les points alloués à ce gros scénario?

Non, mais c'est un bon guide.

Les responsables de produit doivent-ils participer à l'estimation?

Normalement, non. Les votes des responsables de produit peuvent tirer les estimations à la baisse. De plus, ce n'est pas leur expertise, alors leur participation n'a pas autant de valeurs que celle des développeurs, analystes et testeurs.

D'un autre côté, de l'information importante peut émerger de leur participation au planning poker. Nous avons déjà vu des responsables de produit y prendre un certain plaisir et fournir des estimations plus élevées que les développeurs : ils profitent alors de l'occasion pour expliquer que leur vision de ce scénario comporte des détails qu'ils n'avaient pas cru nécessaire d'expliquer. Vous pouvez essayer avec les responsables de produit qui ont bien compris ce qu'est la collaboration... et qui n'essaient pas d'avoir des fonctionnalités pour moins cher.

Doit-on faire une moyenne avec les estimations?

NON! Il est important que tout le monde soit d'accord avec le résultat de l'estimation. Des estimations divergentes sont le point de départ d'une discussion qui résultera en une compréhension commune plus exacte du problème.

En cas de divergences entre deux valeurs qui se suivent sur l'échelle, il faut choisir la plus élevée.

En présence de points de vue irréconciliables, on passe à la prochaine et on s'assure qu'une tâche de recherche liée à ce sujet sera ajoutée au carnet du produit (product backlog).

La complexité, ou la 'taille' en points, doit-elle inclure le risque?

Officiellement, la taille d'un scénario est définie par Mike Cohn (Agile Estimating and Planning) en ces termes : "There is no set formula for defining the size of a story. Rather, a story-point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on."

L'important est de permettre à l'équipe de discuter des moyens d'atténuer les risques qui sont identifiés. Une bonne pratique est d'évaluer les scénarios avec des hypothèses, ou de reporter leur évaluation à plus tard; les évaluations plus précises rendront les scénarios plus faciles à planifier.

Une tâche de recherche (spike) peut permettre d'éliminer une partie du risque.

haut de la page