Planning Poker® – Mode d’emploi

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.