Le Planning Poker est l’une des techniques d’estimation Scrum les plus populaires. Il se déroule lors de la planification du Sprint et a quelques règles simples. Tous les joueurs deviennent membres de l’équipe de développement et chacun d’eux met simultanément sur la table une carte avec le nombre de points d’histoire 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 le 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. Résumé

Introduction

Le Planning Poker, également appelé Scrum Poker ou Pointing Poker, est une technique relative pour 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 au sein de l’équipe Scrum concernant l’estimation de la difficulté des tâches données aux développeurs.

Comment jouer au Planning Poker ?

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

Les cartes de points d’histoire contiennent généralement des valeurs correspondant à la suite de Fibonacci, c’est-à-dire 0, 1, 3, 5, 8, 13, 20, 40 et 100. Il arrive aussi qu’elles soient marquées avec des puissances successives de 2, c’est-à-dire 2, 4, 8, 16, 32, et ainsi de suite. Pourquoi ne sont-elles pas des nombres consécutifs ? Parce que le Planning Poker vise à montrer clairement les différences entre la difficulté des tâches. Et des différences trop petites entre les valeurs des cartes obscurciraient les jugements.

Les nombres expriment généralement le nombre de points d’histoire. Cependant, ils peuvent également être d’autres unités de mesure utilisées par l’équipe Scrum. Nous avons écrit plus sur les unités d’estimation et les points d’histoire dans cet article.

Règles du Planning Poker

Les éléments du jeu de Planning Poker :

  • un jeu de cartes avec des User Stories – préparé séparément pour chaque partie
  • un jeu de cartes avec des points d’histoire – un jeu pour chaque développeur, pour une utilisation répétée

Les phases du Planning Poker :

  1. Présentation de la User Story
  2. Discussion
  3. Jeu (Les phases 2 et 3 se répètent jusqu’à atteindre un consensus de tous)
  4. Consensus
  5. Passer à la User Story suivante

Le Planning Poker a généralement lieu lors de la planification du Sprint. Le Product Owner détient les cartes des User Stories et les développeurs reçoivent un jeu de cartes avec des points d’histoire.

Le modérateur est le Product Owner qui commence 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 la présentation d’une User Story.

La prochaine étape est de commencer 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 concerne, entre autres, des questions telles que :

  • l’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
  • les tâches supplémentaires liées à l’exécution de la User Story.

Lorsque les développeurs s’accordent sur les questions les plus importantes, chacun choisit une des cartes de son jeu de points d’histoire. Ensuite, ils la placent selon leur opinion sur la carte de la 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 retournent à 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 tirent à nouveau jusqu’à atteindre un consensus.
  • Si les développeurs s’accordent sur la User Story, ils passent à la prochaine ronde 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 actuel soit épuisé.
Technique Scrum : Planning Poker

Avantages et inconvénients du Planning Poker

L’avantage du Planning Poker est sans aucun doute la standardisation du travail avec les User Stories. L’équipe de développement dispose entre ses mains d’un ensemble 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é de la tâche. 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 posés parce que, par exemple, les développeurs se sont concentrés sur les aspects techniques de la tâche.

Un autre bénéfice du jeu de Planning Poker concerne le développement de la compétence à 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 atteindre un consensus est également l’un des inconvénients les plus souvent cités du Planning Poker. Si un ou plusieurs développeurs ne sont pas disposés à s’accorder avec les autres, le jeu peut potentiellement s’éterniser indéfiniment.

planning poker

Résumé

Le Planning Poker est une technique d’estimation relative très efficace. L’équipe de développement dispose d’un cadre prêt à l’emploi d’activités et de valeurs de points pour estimer le temps et la difficulté des tâches. Cela leur permet de se concentrer sur des discussions de résolution de problèmes ainsi que 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é de petites abeilles actives sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Caroline Becker

En tant que chef de projet, Caroline est une 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 pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.

View all posts →

Scrum Guide:

  1. Glossaire des termes, rôles et notions de base
  2. Qu'est-ce que Scrum ?
  3. Valeurs Scrum
  4. Comment mettre en œuvre Scrum dans votre entreprise ?
  5. Équipe Scrum - qu'est-ce que c'est et comment ça fonctionne ?
  6. Qui est un Product Owner ?
  7. Les erreurs les plus courantes du Product Owner
  8. Qui est le Scrum Master ?
  9. Les erreurs les plus courantes des Scrum Masters
  10. Quelles statistiques et métriques le Scrum Master devrait-il suivre ?
  11. Équipe de développement en Scrum
  12. Les erreurs les plus courantes des développeurs
  13. Artifacts Scrum
  14. Élargir Scrum
  15. Backlog de sprint
  16. Qu'est-ce que le Product Backlog ?
  17. Qu'est-ce que les User Stories ?
  18. Créer la meilleure User Story avec INVEST
  19. Les erreurs les plus courantes dans les User Stories
  20. Critères d'acceptation de l'histoire utilisateur
  21. Estimation et Points d'Histoire dans Scrum
  22. Planning Poker
  23. Jeu d'estimation d'équipe
  24. Définir l'incrément
  25. Événements Scrum
  26. Qu'est-ce qu'un graphique d'avancement ?
  27. Avantages et inconvénients du graphique de burndown
  28. Tableaux Kanban dans Scrum et Scrumban
  29. Vélocité en Scrum - Vitesse de l'équipe de développement
  30. Scrum quotidien
  31. Planification de Sprint
  32. Revue de Sprint
  33. Qu'est-ce qu'une rétrospective de sprint ?
  34. Erreurs courantes lors d'une rétrospective de Sprint
  35. Nourrir le backlog produit
  36. Comment créer et interpréter un graphique de burndown ?
  37. Qu'est-ce qu'un Sprint dans Scrum ?
  38. Coopération entre le Product Owner et le Scrum Master
  39. Engagements de l'équipe Scrum - Objectif produit, objectif de sprint et définition de la complétion
  40. Caractéristiques d'un bon Scrum Master