Faire un Poker planning simple et efficace

Outils

Nous allons voir dans comment gérer les différentes propositions des équipiers lors d’un vote et cela le plus rapidement possible sans qu’il n’y ait de trop longues discussions. En effet les discussions sont le point le plus chronophage lors d’un Poker planning :

Les cartes que je préconise sont les suivantes :

• « ? » indique qu’un équipier n’as pas assez d’information pour se permettre un Vote.
• « NSP » est une carte que j’ajoute quand l’équipier n’est pas concerné par l’US en question et s’il n’a aucun avis sur la question.

NB : j’informe les équipiers que même s’il ne se sent n’est pas concerné mais qu’il a quand même une idée de la charge de travail d’un équipier il doit se permettre un vote.

Postulat de base

• La description des taches (US, TRIN ou sous tache) est connue de l’équipe, elles ont déjà été présenté à l’équipe lors d’un PBR (product backlog refinement). Les équipiers ont déjà compris individuellement les tâches.

NB : Je pense qu’avoir dans la même réunion la présentation détaillée de la tâche faite par le PO puis d’enchainer sur le vote dans la foulée est une mauvaise pratique. Souvent les équipiers ont besoin d’un moment de réflexion et c’est plus confortable pour eux de ne pas être pris au dépourvu avec une demande de résultat immédiate : c’est très anxiogène. Cela n’empêche pas un rappel de la demande avant de procéder au vote.

• Définition et formation du poker planning aux équipiers : Le poker planning estime une charge de travail, il faut insister sur le fait de décorréler le temps passé sur une tache. Divers exemples existent pour aider à la compréhension. Personnellement pour les collaborateurs n’ayant jamais fait de poker planning et pour aider aux 5 premières estimations, je conseille aux Scrum Master de transférer ce tableau avec le message suivant suite à une brève formation d’équipe dans le mail d’invitation à la cérémonie.

IMPORTANT : Le temps n’est pas pris en compte et c’est normal, il faut penser en termes de charge de travail et de complexité de la tache de manière subjective et selon votre ressentis. Les points ne sont pas du temps ! Ci-joint un tableau d’aide à la décision pour vos premières estimations.

• Explication du principe de vélocité : Afin de rassurer les équipiers qu’ils peuvent faire des votes purement subjectifs et que c’est la bonne pratique, il faut leur présenter des Burndown chart factice et insister sur le fait que c’est un schéma et des statistiques dans le but de les protéger et de leur permettre de travailler dans des conditions optimales. J’aime appuyer avec des exemples de pratique courante comme les demandes « à la volé » de certain supérieur hiérarchique, les changements de scope en cours de développement, ou les pressions de deadline. L’agilité et sa structure ne permettent plus ce genre de pratique, justement car l’équipe aura désormais une vélocité attitrée. J’ouvre la fin de la présentation sur le fait qu’une fois cela mis en place, les réels disfonctionnements peuvent être mis en avant : cela ne vient pas forcément de la qualité de travail des équipiers mais tout simplement un problème de staffing ou d’absence de compétences nécessaires.

• Une fois ces principes rappelés à l’ensemble des équipiers, le scrum master est le maitre de cérémonie du poker planning. Il va lister une par un l’ensemble des US et demander à chaque équipier de donner une note de difficulté/complexité de la tâche de manière subjective. Le PO est là pour apporter des compléments d’information, le Scrum master doit être clair sur le fait que le PO ne participe pas au vote et n’as pas son mot à dire sur les notations qu’il voit. Il est important que le résultat du vote de chacun soit dévoilé en même temps. Il ne faut pas que certain répondent avant les autres afin d’éviter d’influencer le résultat par peur de « dire n’importe quoi ». Il faut désensibiliser les équipiers sur le fait que personne ne dit n’importe quoi, que leur ressentis et subjectivité est la voie à suivre. Le Scrum master doit être rassurant sur ce point.

Interprétation des votes

Voici quelques règles que le Scrum master doit avoir en tête pour établir les bonnes valeurs de Story point par US :

Lexique :

Échelons : c’est le delta entre chaque note : entre 2 et 3 il y a 1 échelon, entre 2 et 5 il y a 2 échelons entre 2 et 13 il y a 4 échelons.

L’objectif des règles suivantes est de savoir à quel moment un temps de discussion doit être ouvert car il y a trop de différences dans les votes.

1. Je ne pose pas comme objectif que tous les équipiers s’accordent sur la même note. Je n’ouvre pas de discussion à chaque US si les notes sont similaires.

2. Lors des phases de discussion je demande toujours si un des équipiers veux absolument défendre sa note et s’il a une conviction et certitude profonde sur son estimation.

Après ses explications et s’il a convaincu certaine personne je pondère plus fortement sa notation (X2). S’il n’a pas convaincu ses coéquipiers et que les votes restent identiques je pondère quand même à la hausse sa note.

Si un coéquipier veut franchement défendre une note différente à ce moment-là on ouvre un temps de discussion plus long jusqu’à ce que l’un des deux change sa note et change la donne du vote.

3. J’ai pour habitude de pondérer plus fortement (X2) la note de la personne qui va être en charge de la réalisation de l’US.

4. Cas le plus simple les équipiers ont tous la même note à l’unanimité  
5. En cas d’égalité nous choisissons la note la plus élevé :  
6. S’il y a n’y a qu’un échelon de différence on opte pour la valeur majoritaire : Une brève discussion est tout de même engagée pour voir si un 2 se change en 3 sinon c’est la majorité ➡️ 2Attention si l’équipier qui est en charge de la réalisation de l’US est un 3 alors l’US sera estimé à 3 car on arrive sur une égalité ➡️ 3

    

7. S’il Ya plus de 2 échelons de différence sur les notes je propose que les groupes ou personnes qui sont concerné par les extrêmes engage une brève discussion : 2 et 5 discutent brièvement entre eux. Soit leur discussion est percutante pour les autres équipiers et un nouveau vote est lancé, soit ils ne sont pas d’accord et c’est le vote majoritaire ➡️ 3Dans ce cas nous avons 2 groupes qui doivent entrer en discussion, s’ils ne tombent pas d’accord ce sera la note la plus élevé qui sera retenue ➡️ 5 

    

8. Le vote disparate :
   • Dans ce cas le scrum master demande au PO de redéfinir clairement le scope et le cadre de l’US : un point de discussion ouvert est entamé pour définir d’où vient l’incompréhension.

   L’objectif de la discussion est de cibler clairement le problème, parfois cette US peut repartir en redéfinition du besoin ou R&D. En attendant elle est estimée à 21.

    

   Rappel : Le scrum master doit être attentif lors des discussions et faire preuve d’une intelligence de lecture des personnes pour jauger la pertinence des propos et si cela apporte une vraie valeur argumentaire dans le cadre de l’US