Guide de mêlée | 24. Planification du poker

Le Planning Poker est l'une des techniques d'estimation Scrum les plus populaires. Il a lieu pendant la planification de sprint et a quelques règles simples. Tous les joueurs deviennent membres de l'équipe de développement et chacun d'eux pose simultanément sur la table une carte avec le nombre de Story Points pour estimer la tâche décrite par le Product Owner. Quels sont les avantages et les inconvénients du Planning Poker, et comment y jouer ? Jetez un œil à notre article pour découvrir et maîtriser la technique.

Planning Poker – table des matières :

1. Introduction
2. Comment jouer au Planning Poker ?
3. Règles du Planning Poker
4. Avantages et inconvénients du Planning Poker
5. Sommaire

Introduction

Le Planning Poker, également appelé Scrum Poker ou Pointing Poker est une technique relative permettant d'estimer la quantité de travail nécessaire pour accomplir une tâche spécifique. Il a été créé en 2022 par James Grenning. Il voulait résoudre le problème des disputes sans fin dans la Scrum Team concernant l'estimation de la difficulté des tâches confiées aux Développeurs.

Comment jouer au Planning Poker ?

Le but du Planning Poker est d' estimer la difficulté et l'effort de chaque User Story sélectionnée pour un Sprint donné. Les règles du jeu Planning Poker sont simples. Cependant, vous devez d'abord préparer les accessoires nécessaires.

Les cartes Story Point contiennent généralement des valeurs correspondant à la suite de Fibonacci, soit 0, 1, 3, 5, 8, 13, 20, 40 et 100. Il arrive aussi qu'elles soient marquées par des puissances successives de 2, soit 2, 4 , 8, 16, 32, etc. Pourquoi ne sont-ils pas des numéros consécutifs ? Parce que Planning Poker consiste à montrer clairement les différences entre la difficulté des tâches. Et de trop petites différences entre les valeurs des cartes obscurciraient les jugements.

Les nombres expriment généralement le nombre de Story Points. Cependant, il peut également s'agir d'autres unités de mesure utilisées par l'équipe Scrum. Nous avons écrit plus sur les unités d'estimation et les Story Points dans cet article.

Règles du Planning Poker

Invites de jeu Planning Poker :

• un jeu de cartes avec User Stories – préparé séparément pour chaque jeu
• un jeu de cartes avec Story Points - un jeu pour chaque développeur, pour une utilisation répétée

Les phases du Planning Poker :

1. Présentation des histoires d'utilisateurs
2. Discussion
3. Gameplay (les phases 2 et 3 sont répétées jusqu'à l'obtention d'un consensus de tous)
4. Consensus
5. Passer à la prochaine User Story

Le Planning Poker a généralement lieu pendant le Sprint Planning. Le Product Owner détient les cartes User Stories et les Développeurs reçoivent un jeu de cartes avec des Story Points.

Le modérateur est le Product Owner qui démarre le jeu en présentant une User Story aux autres membres de l'équipe Scrum. S'ils ont des questions, ils doivent s'exprimer immédiatement après avoir présenté une User Story.

L'étape suivante consiste à lancer une discussion sur la mise en œuvre de la User Story. Toute l'équipe Scrum participe à la discussion, mais les principaux participants sont les développeurs. La discussion porte, entre autres, sur des questions telles que :

• aspect technique de la tâche
• les compétences des développeurs individuels qui seront nécessaires pour accomplir la tâche
• les moyens de faire face aux difficultés attendues
• tâches supplémentaires liées à l'exécution de la User Story.

Lorsque les développeurs se mettent d'accord sur les problèmes les plus importants, ils choisissent chacun une des cartes de leur deck Story Point. Ensuite, ils le placent en fonction de leur opinion sur le cad User Story qui reflète le mieux son niveau de complexité.

La prochaine étape dépend de la façon dont les cartes ont été distribuées :

• Si les Développeurs ont placé des cartes de valeurs différentes sur la table, ils reviennent à la discussion. Ensuite, ils retirent les cartes de la table et ré-estiment la valeur de la User Story. La situation se répète et les développeurs dessinent à nouveau jusqu'à ce qu'ils parviennent à un consensus.
• Si les développeurs sont d'accord sur la User Story, ils passent au tour suivant de Planning Poker. Le Product Owner présente la User Story suivante, et la procédure se répète jusqu'à ce que le pool de User Stories prévu pour le Sprint en cours soit épuisé.

Avantages et inconvénients du Planning Poker

L'avantage de Planning Poker est sans aucun doute la standardisation du travail avec les User Stories. L'équipe de développement tient entre ses mains un jeu de cartes prêt à l'emploi pour calculer la quantité de travail. Cela permet aux valeurs de chaque Sprint de rester constantes et l'équipe apprend à estimer avec des unités spécifiques.

Un autre avantage important est la participation égale de tous les développeurs à l'estimation de la complexité des tâches. Même les personnes qui ne sont pas directement impliquées dans son exécution peuvent contribuer à la discussion. Par exemple, en attirant l'attention sur des problèmes qui ne se sont pas produits parce que, par exemple, les développeurs se sont concentrés sur les aspects techniques de la tâche.

Un autre avantage de jouer au Planning Poker concerne le développement de l'habileté à fixer des limites de temps sur la discussion et, si nécessaire, à limiter le nombre de tours joués pour chaque User Story.

Cependant, le temps nécessaire pour parvenir à un consensus est également l'un des inconvénients les plus fréquemment cités du Planning Poker. Si un ou plusieurs développeurs ne veulent pas être d'accord avec les autres, le jeu peut potentiellement traîner indéfiniment.

Sommaire

Planning Poker est une technique d'estimation relative très efficace. L'équipe de développement dispose d' un cadre d'activités prêt à l'emploi et de valeurs de points pour estimer le temps et la difficulté des tâches. Cela leur permet de se concentrer sur les discussions de résolution de problèmes et d'améliorer leurs estimations en comparant les calculs et les User Stories en temps réel.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit