Mode d’Emploi du Planning Poker® et Explication
Le Planning Poker® est un jeu de cartes dédié aux professionnels qui souhaitent réaliser une estimation relative de leur plan d’actions. Cette technique facilite le consensus de groupe, y compris avec les débutants, et favorise l’engagement de l’équipe face au travail à réaliser.
Elle permet également d’éviter de découper les éléments à réaliser en éléments trop atomiques comme le nécessite systématiquement la technique d’estimation en temps idéal. Nous vous proposons de découvrir précisément cette technique et ses variantes avec nos posters résumant cette activité qui est devenue depuis 2008 un outil indispensable pour les équipes agiles.
Un peu d’histoire
Le planning poker est une technique d’estimation inventée par James Greening, l’un des 17 signataires du « Manifesto for Agile Software Development ». Il s’agit d’une série de cartes qui suit la suite de Fibonacci : « 0 1 1 2 3 5 8 13 21 34 55 89 ? Café ».
Ce jeu de cartes permet en très peu d’échanges d’établir un consensus de groupe. Sa rapidité fait qu’elle est souvent utilisée par les équipes agiles pour estimer les éléments de leur travail. Mike Cohn y ajoute la notion d’erreur pour rappeler aux ScrumMasters (Facilitateurs de groupe) et aux équipes que l’erreur fait partie intégrante de nos modèles de pensées. Il modifie ainsi la suite de Fibonacci, proposée par James Greening, et la transforme en « 0 1/2 1 2 3 5 8 13 20 40 100 ? Café ».
Pourquoi une technique d’estimation relative ?
Il y a une bonne et une mauvaise façons d’utiliser la technique d’estimation en temps idéal. La mauvaise est de considérer que le temps idéal a un lien linéaire avec le temps réel. L’incompréhension de ces deux notions induit fréquemment un état de stress chez les managers. Ils assimilent à tort le ratio entre le temps idéal et le temps réel comme une notion d’efficience ou d’efficacité.
La bonne façon est de passer à une notion de Complexité avec une triangulation, le lien entre Complexité et temps réel disparaît et les variations entre les deux notions ne sont plus perçues comme un bruit cognitif. La seule interrogation, qui subsiste parfois chez les managers après avoir compris le nouveau concept, est de savoir comment retrouver une estimation globale en temps de toute la liste d’éléments.
Objectif
Comme dit ci-dessus, l’objectif du planning poker est double :
- Il consiste à estimer un ensemble d’éléments représentant un besoin. Cet ensemble peut former plusieurs centaines d’éléments. (cf. Image n°2)
- Il permet de favoriser l’engagement d’une équipe.
Mode d’Emploi
Le mode d’emploi passe dans un jeu de rôle et dans le déroulé. Les Rôles (cf. Image n°3) présents dans un Planning Poker® sont :
- 1 Facilitateur souvent représenté dans une équipe Agile par le leader responsable de l’organisation d’équipe : le ScrumMaster.
- 1 Equipe composée par un ensemble de personnes ayant la capacité de transformer le besoin en une solution concrète, reçoit individuellement un jeu de cartes (cf. Image n°4) contenant les 13 cartes suivantes : 0 1/2 1 2 3 5 8 13 20 40 100 ? Pause Café.
- Client, représenté dans le Management de Produit par un ProductOwner, le leader responsable de l’ordonnancement de la liste.
Le processus se déroule en 2 étapes essentielles :
- A. Le Référentiel
- B. La Triangulation
A. Le Référentiel
Cette étape consiste à choisir un référentiel de triangulation. Le but est d’obtenir deux éléments qui permettent de positionner les autres. Cette technique est une technique classique en ingénierie télécom, astrophysique et géographie, par exemple. A partir de deux éléments, nous cherchons sur une échelle à positionner un troisième élément.
Pour se faire :
- Le ScrumMaster sélectionne avec l’aide de l’équipe un échantillonnage significatif de la liste d’éléments. Cet échantillonnage représente une dizaine d’éléments. (cf. Image n°6)
- Le ScrumMaster demande alors quel est l’élément le moins complexe. Le mot « Complexe » signifie que l’élément nécessite moins de travail que les autres éléments ; il y a moins de risques techniques et est a fortiori plus facile à faire que les autres. (cf. Image n*7)
- Par la suite, le ScrumMaster demande à l’équipe de déterminer visuellement celui qui demande le plus de travail, celui qui est le plus flou et à la fois le plus risqué. (cf. Image n°8)
- Le ScrumMaster écrit sur l’élément le moins complexe la valeur C 3 (C pour Complexité) et sur le plus complexe la valeur C 13.
AUTRES POSSIBILITÉS
Pour initier le référentiel, il existe plusieurs autres variantes techniques.
- Il est possible de choisir d’autres valeurs « 2 et 8 » ou « 2 et 13 ». Il faut cependant garder un peu de marge en dessous et au dessus des 2 éléments du référentiel afin de prévoir qu’une bonne partie de la liste d’éléments se positionne sur les valeurs inférieures et supérieures afin de ne pas passer trop de temps à chercher à les fusionner et à les découper.
- Il est aussi possible de venir avec 2 éléments choisis par le ScrumMaster. Et il présente à l’équipe le moins et le plus complexe et leur demande leur confirmation. Le ScrumMaster appose alors 3 et 13 (ou 2 et 8) respectivement sur les 2 cartes.
B. La Triangulation
Le Planning Poker se poursuit avec l’étape de Triangulation.
- Le Product Owner présente l’élément fonctionnel à l’équipe. Les membres de l’équipe ne parlent pas. Ils écoutent seulement. (Cf. Image n°10)
- Le ScrumMaster compte jusqu’à 3. (Cf. Image n°12)
- Le ScrumMaster dit « 1 ». Chaque membre d’équipe sélectionne une carte. Sur la suite de poker entre 0 à 100, combien évaluez-vous l’élément ? (Cf. Image n°13)
- Le ScrumMaster dit « 2 ». Il la retourne face chiffrée vers la table.
- Lorsque toutes les cartes ont été retournées face vers la table, le ScrumMaster dit « 3 » puis tous les membres de l’équipe retournent leur carte et rendent visible leur choix. (Cf. Image n°14)
Le Résultat de la Triangulation demande au ScrumMaster de faire émerger un protocole de consensus ; chaque litige est alors étudié par l’équipe ou le ScrumMaster pour en proposer une règle simple. Le protocole le plus rapide et performant, alliant une période de silence et de l’action avec un véritable consensus, est le suivant :
- Si l’ensemble des cartes varient sur trois chiffres consécutifs de la suite de Fibonacci modifiée, par exemple 5, 8, 8 et 13 correspondant aux cartes de 4 membres d’équipes, l’estimation résultante est 8. De la même façon, 1, 2, 3, 3 donnerait 2. Ce protocole se démontre en Atelier pour convaincre les personnes. Et la conclusion de la démonstration permet de prouver que l’on a souvent de 3 qui se mesure comme étant un 5, et parfois même comme étant un 8. Un ScrumMaster dirait alors : « Un 5 vaut un 3 ; Un 5 vaut parfois aussi un 8 ; dans tous les cas, cela ne change rien au résultat final ». (Pourquoi y-a-il un consensus ? Cf. Autre article)
- Si c’est 1, 3, 3, 3, on choisit 2. La valeur que personne n’a trouvé. Mais puisqu’elle se situe sur le segment 1,2 et 3, on prend la valeur du milieu : 2.
- Si les chiffres résultants sont consécutifs avec un faible écart comme les 4 choix suivants : 8, 8, 13 et 13, le consensus sera alors 13. Le résultat s’obtient par un raisonnement par l’absurde. Si vous donnez 8, l’équipe pensera (probablement à tord) que le ScrumMaster est entrain de leur mettre la pression. Pour éviter cette croyance, nous prenons la valeur supérieure.
- S’il y a un consensus, le protocole repart avec un nouvel élément à l’image n*10 et la description du Product Owner.
AUTRE VARIANTE DE PROTOCOLE
- Certaines équipes préfèrent discuter les extrémités des variations comme 5, 8 et 13 lorsqu’il y a 3 chiffres consécutifs. Pourquoi pas ! Même si cela est inutile. Si les équipes manquent de maturité, le ScrumMaster peut accepter ce protocole. Cela ira moins vite et il y aura beaucoup plus de discussion mais le Planning Poker marche aussi comme cela. L’engagement sera ainsi respecté.
- Cependant, si l’on observe (cf. Image n°17, 18) des écarts plus importants, comme 2, 3, 8 et 13, on estime qu’il n’y a pas de consensus et que les extrémités doivent s’exprimer. A tour de rôle, le ScrumMaster leur donne la parole pour expliquer leur choix ; puis le Product Owner (cf. Image n°19) redonne du détail sur l’élément à évaluer avec ce qu’il vient de comprendre de leur niveau de compréhension du besoin.
- Puis un Second Vote est lancé. (cf. Image n°20)
- S’il y a un consensus, le ScrumMaster écrit sur l’élément la Valeur consensuelle et le protocole repart avec un nouvel élément à l’image n°10.
- S’il n’y a pas de consensus, le ScrumMaster replace l’élément sous le paquet d’éléments qu’il a entre les mains ;
- Puis l’élément sera réévalué une dernière fois lorsque tous les éléments du dessus auront été évalués en suivant le protocole précédent.
- Si l’élément sort de ces 3 évaluations avec un écart, il sera apposé sur la carte un « ? ».
- Puis une étape d’exploration, appelé Spike, sera proposée.
En conclusion, le planning poker est l’une de nos techniques d’estimation avancée. Elle est simple à utiliser et efficace. Le temps passé à faire une estimation avec le Planning Poker peut faire gagner du temps dans les estimations. Autrefois, nous estimions des produits en temps idéal et seuls les experts du groupe parlaient. On ne pouvait pas réellement parler de consensus et lorsque ces experts partaient du groupe, l’équipe ne voulait plus s’engager sur une valeur qui leur semblait maintenant devenue « fausse ». Nous remarquons aussi que les débutants et les stagiaires sont aussi capables d’estimer une liste d’éléments ce qui n’était pas le cas avec la notion de temps idéal.