Comment faire un poker planning efficace ?

Définition : Le poker planning est une technique de planification agile très largement adopté par les utilisateurs du framework Scrum. Elle vise à estimer la complexité d’un travail à réaliser par les membres de l’équipe de développement. Ce qui fait la force de cette technique c’est que l’estimation du travail se fait de manière « simultanée » par l’ensemble des membres de l’équipe, ce qui limite les biais de groupe qui pourraient faire pression sur le choix des collaborateurs dans leur estimation. En favorisant la prise de décision collective, cette technique permet de planifier le travail de façon collaborative et transparente. 

Quiz :

Qu’est-ce que la technique du poker planning dans le cadre d’un projet agile ? 

1. Une estimation relative   
2. Une estimation déterministe 
3. Une estimation probabiliste  
4. Une estimation absolue 

Corrigé du quiz en bas de cet article [1]  

Le poker planning : C’est quoi ? C’est qui ? C’est quand ? 

Savez-vous quelle est la différence entre le Poker Planning et la Delphi Technique ? Eh bien, il n’y en a pas ! Le Poker Planning et la Delphi Technique sont toutes deux des techniques collaboratives qui cherchent à éviter les biais de groupe, en impliquant l’ensemble de l’équipe dans un processus d’estimation du travail à fournir sans crainte d’être influencé par l’opinion des autres.

La Delphi Technique a été développé au milieu du XXème siècle par un scientifique militaire du nom de Norman Dalkey, et par un statisticien du nom d’Olaf Helmer, au sein de la RAND Corporation (un think thank américain). Son processus est itératif, on demande à un groupe d’experts de participer à des tours successifs de questionnaires anonymes et de feedbacks contrôlées. L’idée étant d’obtenir un consensus graduel parmi les experts sur un sujet particulier. Cette approche est souvent utilisée pour prendre des décisions dans des situations complexes et incertaines, en exploitant la sagesse collective des experts.

Quant au Poker Planning, celui-ci a été inventé par l’un des 17 signataires du manifeste agile « James Grenning » et popularisé par « Mike Cohn » dans son livre Agile Estimating and Planning. Le poker planning utilise, comme son nom l’indique, un jeu de cartes, où chaque membre de l’équipe [2] reçoit un jeu de 12 cartes représentant la suite de Fibonacci (cf. schéma n°1) pour pouvoir voter de manière itérative et indépendante sur le travail à réaliser (généralement il s’agit de Users Stories). L’idée sous-jacente de cette approche est de pouvoir mesurer la capacité de travail et la vélocité de l’équipe [3]. En effet, les enjeux de productivité et de compétitivité peuvent générer du stress et de l’appréhension sur les délais de réalisation des travaux à fournir. Le poker planning vise a atténuer ces menaces en favorisant des estimations indépendantes. Comment ? Eh bien, grâce à la technique du « en même temps ». Les collaborateurs vont abattre leur carte « en même temps » ce qui va obliger les membres de l’équipe à s’engager dans une estimation sans pouvoir consulter les autres (sans triche donc 😉) et sans pouvoir être influencé par les autres.

Pourquoi la suite de Fibonacci ?

Sur chaque carte du jeu du poker planning, on retrouve des métriques non linéaires telles que la Suite de Fibonacci ou des Tailles de T-shirt. Cette astuce permet d’avoir une visibilité plus « marquée » de l’information. Pour mieux saisir cette idée, imaginez l’évaluation de la difficulté de 3 montagnes à gravir selon 3 niveaux de difficulté distincts, disons une difficulté de 30 pour la montagne n°1, 40 pour la montagne n°2 et 50 pour la montagne n°3. Maintenant, si on vous dit que ces 3 montagnes sont de difficulté 34, 55 et 89. La deuxième approche favorisera, une compréhension « plus tranchée » des niveaux de difficulté. Ce qui facilitera la communication de l’information. On passe de « Oh, ça va être difficile » à « Attendez, on va avoir besoin d’un tapis volant ! 😊

Schéma n°1 : illustration du jeu de cartes du poker planning

Comment faire un poker planning efficace ?  

👉Etape 0 : Chaque membre de l’équipe de développement récupère son jeu de 12 cartes représentant la suite de Fibonacci (cf. schéma n°1) pour voter et le scrum master se tient prêt à animer cette réunion (on peut aussi confier ce rôle à un membre de l’équipe pour faciliter l’empowerment).

👉Etape 1 : le product owner sélectionne une user story du product backlog pour la lire à voix haute.

• • Exemple de dialogue :
  • Thomas (le product owner) : indiquez-moi les points d’effort nécessaires pour « faire ses lacets »?
  • Loana (Un membre de l’équipe de développement) : attend, attend, tu parles du niveau d’effort nécessaire pour faire ses lacets à l’âge adulte ou quand on était enfant ?
  • Mehdi (Scrum Master) : Loana, tu n’étais pas là lors du backlog refinement ? (le Scrum Master intervient simplement pour comprendre ce qu’il s’est passé car normalement, il ne devrait pas y avoir beaucoup de questions de compréhension sur les users stories puisqu’elles sont censées déjà avoir été expliquées lors de l’affinage du backlog.
  • David (Un membre de l’équipe de développement) : Cher Mehdi, rappelle toi, Loana n’était pas là lors du backlog refinement, elle était en vacances !
  • Mehdi (Scrum Master) : Ah oui c’est vrai, oui oups excusez-moi !

👉Etape 2 : comme au poker, tous les membres de l’équipe de développement [2] choisissent secrètement une carte parmi les cartes qu’ils ont dans la main, représentant l’estimation du niveau d’effort à fournir pour faire « faire ses lacets ». Le Scrum Master vérifie que tous les membres ont bien choisi une carte parmi les 12 qu’ils ont dans la main. 

👉Etape 3 : Une fois que les cartes de chacun sont posées avec la face contre table, le Scrum Master invite chacun à tourner ses cartes « en même temps » en leur demandant de tourner leur carte.

• • Mehdi (Scrum Master) : on tourne !
  • L’ensemble des membres de l’équipe de développement: chacun des membres de l’équipe tourne ses cartes en même temps !

Puis chacun observe les chiffres sélectionnés (David a sélectionné le chiffre « 5 », Loana a sélectionné le chiffre « 8 », Mathieu a sélectionné le chiffre « 5 », Franck a sélectionné le chiffre « 2 » et Sonia a sélectionné le chiffre « 5 »).

Point important ! On ne fait jamais d’estimation sur les durées des tâches comme en approche de développement prédictive (estimation triangulaire, estimation paramétrique, analogique, etc.) mais sur le niveau d’effort que représente la fonctionnalité ou la user story. C’est d’ailleurs pour cela qu’on parle de points d’effort (story point). Ce niveau d’effort est estimé selon l’acronyme « CURSE » pour « Complexité, Uncertainty, Risk, Scope, Effort » désignant le niveau de complexité, d’incertitude, de risque, de maîtrise du périmètre (ou de travail à fournir) et d’intensité d’effort que représente le travail à fournir. On est dans l’univers de l’agilité (et donc de l’incertitude), donc on ne peut pas utiliser des techniques aussi précises que dans l’univers du prédictif !

Poker Planning : comment gérer les désaccords ? 

Comme je l’indiquais en préambule, les enjeux de rendement peuvent entraîner une pression de la part du product owner sur l’estimation des membres de l’équipe. Cependant, je rappelle aussi que les équipes sont auto-organisées et qu’il n’y pas de hiérarchie entre le product owner et les membres de l’équipe de développement ni même avec le Scrum Master d’ailleurs (Il n’y a pas d’équipe dans l’équipe ni de hiérarchies. Il s’agit d’une seule et même unité stable, composée de professionnels focalisés sur un seul objectif à la fois, l’Objectif de Produit […] Cf. Guide Scrum, version française). Par ailleurs, il est essentiel de rappeler que dans un contexte agile, une approche transparente, sincère et sans pression exagérée favorise une meilleure qualité et réduit les risques d’erreurs. Une trop forte pression est non seulement inutile mais aussi contre-productive. Autre point, les écarts ne devraient pas être trop importants surtout si les équipes sont « cross-fonctionnels » avec des compétences de « profil en T » [3] (cf. schéma n°2).  Si les écarts sont trop importants cela signifie qu’on est confronté soit à un problème de « compréhension » des users stories, soit à un problème de « compétences ». 

Schéma n°2 : illustration de la compétence de profil en T (T-Shaped Profil) [3]

5 techniques à utiliser en cas de désaccord entre les membres de l’équipe ?

Plusieurs techniques existent pour trancher en cas de désaccord. Regardons les ensemble :

• Technique n°1 « l’argumentation en 1 minute ! »

On va demander à ceux qui ont pris les chiffres les plus éloignés des estimations centrales de discuter. David avait choisit le chiffre « 5 », Loana le chiffre « 8 », Mathieu le « 5 », Franck le « 2 » et Sonia a sélectionné le chiffre « 5 » également. On va donc demander à Franck et Loana d’expliquer leur estimation. Puis on demande à tout le monde de revoter et on voit si les estimations ont bougé un peu ou non.

• Technique n°2 « La médiane »

Pour utiliser cette technique, on regarde les chiffres situés au milieu des estimations. Dans notre exemple, le nombre total de votant est impair (puisqu’on a 5 collaborateurs), ils ont choisi les chiffres suivants : 2, 5, 5, 5, 8 (classement par ordre croissant). Le point d’effort retenu correspondra au chiffre situé au centre de la suite de données : donc ici on retiendra 5 points d’effort. En revanche, si le nombre total de votant avait été pair (supposons 4 collaborateurs qui avaient choisi les chiffres suivants : 8, 13, 21, 34) on aurait pris la moyenne des deux chiffres du centre pour obtenir la médiane. Donc ici (13+21) / 2 = 17. NB : évitez les chiffres à virgule (et toutes autres formes d’usines à gaz !!🤯)  

• Technique n°3 « Jugement à dire d’expert »

Pour utiliser cette technique, on fait appel à un expert indépendant qui va, en toute transparence, faire les estimations relatives et aider l’équipe à se décider.

• Technique n°4 « Consulter la charte d’équipe »

L’équipe est censée s’être créée une charte d’équipe qui explique (entre autres) quelles sont les valeurs de l’équipe, quels sont ses règles de fonctionnement, quels sont ses modes de communication et quels sont des modes de prise de décision. Exemple : on doit se décider pour savoir si on opte pour la solution « Trello plutôt que Jira ».

• • • Prise de décision démocratique : c’est la majorité qui a raison (pour 6 collaborateurs, cela veut dire qu’on doit avoir 4 membres du même avis. La moitié + 1 (c’est le principe de majorité absolue).
    • Prise de décision autocratique: c’est un représentant de l’équipe qui décide pour l’ensemble de l’équipe.
    • Prise de décision par consensus: tout le monde doit être du même avis. (personnellement, je trouve que ce mode de prise de décision est soit trop chronophage, soit trop superficiel). Mais c’est un mode de prise de décision très populaire pour le poker planning ! 
    • Prise de décision à la pluralité: c’est le plus grand nombre du même avis qui l’emporte même si ce n’est pas la majorité (c’est le principe de majorité relative). Exemple : sur 6 collaborateurs, si 2 collaborateurs sont pour l’utilisation du logiciel « Trello » plutôt que l’outil « Jira » et que le 3ème collaborateur est pour « Wrike », le 4ème pour « Monday » et le cinquième pour « Asana » et le 6ème pour « Redmine » (2+1+1+1+1). 

• Technique n°5 « Créer des abaques »

La technique « d’abaque » (cf. schéma n°1) est très recommandé (même sans désaccord) pour avoir un outil de référence qui permette de guider l’équipe dans ses estimations. L’idée étant de pouvoir établir des comparaisons et maintenir une certaine uniformité dans les estimations, en évitant que les membres de l’équipe ne se dispersent trop dans leurs évaluations. C’est d’ailleurs pour cette raison qu’on dit que le poker planning est une technique d’estimation relative (elle est relative par rapport à d’autres). Exemple : cette user story n°15 ressemble beaucoup à la n°18 et on ne lui avait mis que 5 points d’effort !

3 stratagèmes à utiliser en cas de désaccord avec le Product Owner ?

Le Product Owner va vouloir défendre ses propres users stories, et c’est bien normal car il s’agit de celles qui apportent le plus de valeur business. D’un autre côté, l’équipe de développement va vouloir traiter celles qui sont le plus faisables techniquement lors du sprint. Et c’est bien normal car elle va s’engager à « livrer » quelque chose d’exploitable dès la fin du sprint (Les Sprints sont au cœur de Scrum, où les idées sont transformées en valeur […] Cf. Guide Scrum, version française). 

Le product owner évalue la valeur business des fonctionnalités, exprimée en pourcentage, en se basant sur son expertise par rapport au domaine du client. Par exemple, la fonctionnalité « paiement avec double authentification » sur un site internet est évaluée à 90% de valeur business en raison de son impact commercial.

L’équipe de développement évalue quant à elle, la valeur technique des fonctionnalités, exprimée en point d’effort, en se basant sur la technique du « poker planning ». Par exemple, la fonctionnalité « paiement avec double authentification » sur un site internet est évaluée à 55 points d’effort en raison de sa complexité technique. On a d’un côté, 90 % de valeur business et de l’autre 55 points de valeur technique. 

Maintenant, supposons que l’équipe n’ait pu faire, au cours des 5 derniers sprints, que 30 points d’effort (sa capacité par sprint est donc de « 30 » points d’effort [4]). Il y a fort à parier qu’en regardant la user story du product owner, les collaborateurs disent au product owner que celle-ci n’est pas compatible avec le sprint à venir. Le problème c’est que le product owner a absolument besoin de cette fonctionnalité de paiement car c’est un réel « manque à gagner » pour son entreprise. Comment donc « abriter » pour que 100 % des users stories situées en haut backlog (ultra importantes donc) soit livrées à la fin de chaque sprint ? Réponse : Le product owner et l’équipe de développement vont devoir négocier et utiliser des stratagèmes.

Schéma n°3 : vélocité, capacité ou engagement ? [4]

• Stratagème n°1 « penser à l’outcome »

  si la user story est trop grande pour pouvoir être réalisée en 1 sprint, on va s’interroger sur « l’outcome » (le résultat) et non sur « l’output » (la donnée de source). Par exemple, si l’objectif (l’output) c’est de proposer la fonctionnalité de « paiement à double authentification », on va d’abord réfléchir à son « service » pour voir s’il n’existe pas d’autres alternatives moins difficiles techniquement.

Exemple :

• Question : A quoi ça sert la fonctionnalité de « paiement à double authentification » ? (c’est l’output)
• Réponse : ça sert à payer des biens ou services en 3 clics sur un site web (c’est l’outcome)
• Question : Est-ce qu’il existe d’autres alternatives pour payer des biens ou services en 3 clics sur un site web moins difficile à réaliser techniquement ?
• Réponse : Oui, il y a la fonctionnalité « PayPal » qui est accessible en libre-service. Un simple copier-coller suffirait et on aurait un bouton de paiement immédiatement accessible.

Et voilà ! 😎

• Stratagème n°2 « déprioriser certaines users story »

Le product owner doit accepter que 100 % du haut backlog ne sera pas traité à chaque sprint (cf. schéma n°4). Pour rappel, l’équipe doit s’engager à produire de la valeur à chaque fin de sprint (on recherche un effet waouh à chaque sprint !). Si l’équipe à une capacité de fournir 30 points d’effort à chaque sprint et que la somme des 3 users stories est égale à, disons 80 points d’effort, il sera impossible de traiter ces 3 premières tout de suite. Par contre, si en observant bien le backlog, on se rend compte certaines user stories sont plus faciles à réaliser techniquement (même si moins prioritaire d’un point de vue de la valeur business), on pourra suggérer au product owner de déprioriser certaines users stories difficiles à réaliser techniquement au profit d’autres plus faciles à faire techniquement.

Schéma n°4 : valeur business vs valeur technique des users stories

• Stratagème n°3 « faire un compromis sur la qualité »

Parfois, il est plus judicieux de terminer une tâche plutôt que de viser la perfection. Si certaines user stories sont particulièrement cruciales et urgentes, et si la nature du projet le permet, on pourra envisager de livrer rapidement même si cela implique une légère baisse de la qualité du travail accompli. NB : dans les contextes où la sécurité des utilisateurs finaux est en jeu, ce stratagème sera bien entendu à proscrire ! (pour en savoir plus consultez la matrice des compromis ici).

Conclusion

En conclusion, le poker planning limite les biais de groupe tels que les biais de conformité, la pensée de groupe ou encore les effets de groupe. Le poker planning est basée sur des points d’effort plutôt que sur des durées pour favoriser une évaluation plus objective de la complexité des tâches.

L’ensemble de l’équipe doit savoir faire la distinction entre la valeur business et la valeur technique des users stories. Le product owner doit savoir déprioriser le backlog si nécessaire ou faire des compromis sur la qualité si le projet le permet.

Les écarts trop importants dans les estimations peuvent signaler des problèmes sous-jacents tels qu’une mauvaise compréhension du travail à fournir ou des lacunes dans les compétences de l’équipe. La résolution de ces problèmes est essentielle pour optimiser le travail et améliorer la fiabilité des estimations.

Enfin, bien que le bluff soit monnaie courante au poker, au poker planning, on ne bluffe pas ! 😇C’est en jouant cartes sur table que l’on construit la meilleure main possible pour mener le projet à la victoire. 😄🃏

________________________________

__________________________________

Sources et références :

• Bibliographie : Dictionnaire commenté de l’agilité : pourquoi et comment devenir une entreprise Agile. Comprendre le développement agile de produit. Le dire en français. 
• Guide Scrum, version française 2020
• Webographie : Consultez le document original du Poker Planning de James Grenning en cliquant-ici : « Poker Planning or How to avoid analysis paralysis while release planning »

Notes de bas de page : 

[1] Réponse A. Le poker planning est une comparaison avec d’autres estimations. C’est une estimation relative.

[2] Tout le monde vote à l’exception du product owner et du scrum master

[3] La « T Shape » ou « profil en T »  fait référence à une analogie utilisée par les agilistes  pour dire qu’un collaborateur doit être « poly-compétent » avec plusieurs « domaines de compétences » (la barre horizontale du « T ») et une profondeur des connaissances dans chacun de ces domaines de compétences dans un contexte plus large (la barre verticale du « T »). La barre horizontale représente une expertise approfondie dans un domaine spécifique, tandis que la barre verticale représente la capacité à collaborer, à communiquer et à appliquer ces compétences dans des domaines connexes.

[4] La « capacité » d’une équipe représente la quantité maximale de travail qu’elle peut accomplir lors d’un seul sprint, et cette capacité est établie après plusieurs sprints (au moins 5). Par exemple, si une équipe s’engage à réaliser 40 points d’effort sur un sprint de 2 semaines mais ne parvient à accomplir que 30 points d’effort à chaque fin de sprint malgré ses efforts, sa « capacité » est de 30 points d’effort. Lorsque nous évaluons le travail accompli au cours d’un seul sprint, nous utilisons le terme « vélocité » plutôt que « capacité ».

_______________________________