Guide de mêlée | 25. Jeu d'estimation d'équipe

Publié: 2022-05-28

Le jeu d'estimation d'équipe est une technique facilitant la planification de sprint dans Scrum. En quoi diffère-t-il du Planning Poker ? Pourquoi certaines équipes de développement trouvent-elles qu'il s'agit d'un outil plus efficace et d'autres non ? Vous trouverez tout ce que vous devez savoir à ce sujet dans l'article suivant.

Jeu d'estimation d'équipe - table des matières :

  1. Introduction
  2. Règles du jeu d'estimation d'équipe
  3. Jeu d'estimation d'équipe contre Planning Poker
  4. Sommaire

Introduction

Le jeu d'estimation d'équipe est également appelé Swimlanes Estimation. Ce dernier terme est né de l'observation spontanée d'un jeu de cartes car l'affichage des cartes ressemblait aux couloirs de nage d'une piscine d'eau.

Team Estimation Game gagne constamment en popularité, car il permet aux équipes de développement de créer des estimations environ 3 fois plus rapidement qu'en utilisant Planning Poker.

Nous écrivons sur cette technique dans l'article précédent. Aujourd'hui, concentrons-nous sur le jeu d'estimation d'équipe.

Règles du jeu d'estimation d'équipe

Invites du jeu d'estimation d'équipe :

  • un jeu de cartes User Stories - préparées séparément pour chaque jeu
  • un jeu de cartes Story Point - pour une utilisation répétée

Tout d'abord, empilez les fiches User Stories dans l'ordre correspondant aux entrées du Product Backlog. Pour s'assurer que les plus urgents soient estimés en premier.

Les cartes de score contiennent généralement des valeurs correspondant à la suite de Fibonacci. Il s'agit d'une séquence des nombres suivants : 0, 1, 3, 5, 8, 13, 20, 40 et 100. Vous pouvez également les étiqueter avec des puissances successives du nombre 2, c'est-à-dire 2, 4, 8, 16, 32, etc.

Team Estimation Game

Les phases du jeu Team Estimation :

  1. Introduction. Pour jouer au Team Estimation Game, les membres de l'équipe Scrum s'assoient autour d'une table. Le Product Owner commence par tirer la première carte du paquet User Story et partage son contenu avec tous. Ensuite, les cartes restent sur la table. Ensuite, le Product Owner explique au reste de l'équipe Scrum qu'à partir de maintenant, les joueurs évalueront les User Stories comme faciles ou difficiles à mettre en œuvre en les plaçant en conséquence à gauche et à droite. Si l'un d'entre eux rencontre un certain degré de difficulté, le joueur s'empilera, l'un au-dessus de l'autre sur la table. Maintenant, la personne assise à côté d'eux dans le sens des aiguilles d'une montre fait le prochain mouvement.
  2. Un joueur pioche une carte du paquet User Story. Après avoir partagé son contenu avec tous, explique son essence au Product Owner. La personne qui détient la carte la place ensuite sur la table et sélectionne une place en fonction de son avis sur la difficulté de cette User's Story. Ensuite, le joueur explique à tous le raisonnement derrière son choix et l'autre joueur est libre de poser des questions concernant le raisonnement. Ils ne peuvent pas remettre en cause la décision elle-même mais les arguments justifiant la décision.
  3. Maintenant, les joueurs jouent à tour de rôle et ont le choix entre deux options :
    • Répétez l'étape 2, ou
    • Déplacez l'une des cartes sur la table à sa position la plus appropriée

    S'ils optent pour la deuxième option, ils doivent également justifier ce qui les a fait changer d'avis. Les joueurs répètent à tour de rôle l'étape 3 jusqu'à ce que toutes les cartes du paquet User Story soient distribuées et estimées.

  4. L'étape finale de placement des cartes User Story se produit une ou plusieurs fois, selon la pratique de l'équipe Scrum. Au cours de ce tour, chaque joueur a encore une fois l'occasion de déplacer l'une des cartes sur la table à un endroit plus approprié.
  5. Une fois que les joueurs ont attribué toutes les cartes User Stories à leurs emplacements représentant les niveaux de difficulté, l'équipe de développement passe à la valeur correspondante en attribuant les cartes de la pile Story Point. La première carte User Story à gauche obtient la carte Story Point avec le plus petit nombre de points par le Product Owner. La règle pour placer les cartes suivantes est la même que pour les points 3 et 4. Ceci complète l'estimation.
Team Estimation Game

Jeu d'estimation d'équipe contre Planning Poker

Le Team Estimation Game est considéré comme un outil d'estimation plus efficace que le Planning Poker. En raison des différences suivantes entre ces deux techniques :

  • Table à cartes. Le jeu Team Estimation utilise la «règle de la table de cartes» bien connue des jeux de cartes populaires. Cela signifie qu'une fois que vous avez placé une carte, vous ne pouvez pas la reprendre. Étant donné que la User Story est estimée par une personne à la fois, la fluctuation entre les estimations et le nombre de fois où les positions de changement sont significativement plus faibles, par rapport à Planning Poker.
  • Un calcul suffisamment précis. Dans Planning Poker, un consensus complet doit être atteint pour chaque User Story. Dans Team Estimation Game, cependant, une seule personne décide. Même si son estimation est erronée, un autre développeur la placera probablement sur une correspondance plus précise avec sa valeur. De cette manière, nous garantissons une estimation suffisamment précise et rapide
  • Épuiser le sujet de discussion. Argumenter les choix devient souvent excessivement long lorsque vous jouez au Planning Poker. Leur temps est fortement réduit lors d'un Team Estimation Game car ils se concentrent sur une seule décision de l'un des Développeurs plutôt que sur la nature de chaque User Story.

Un inconvénient potentiel du jeu d'estimation d'équipe est un sentiment d'injustice. Si l'équipe de développement est plus grande que le nombre de user stories planifiées dans un sprint donné, certains développeurs peuvent se sentir laissés pour compte.

Jeu d'estimation d'équipe - résumé

Team Estimation Game a une opinion sur la technique d'estimation la plus efficace pour la plupart des équipes Scrum. Cependant, il est important de se rappeler qu'il ne s'agit que d'un outil permettant d'estimer la difficulté et l'effort des User Stories. Et comme tout outil, nous devons l'ajuster pour qu'il corresponde aux besoins et aux capacités des membres de l'équipe.

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

Scrum Guide | 25. Team Estimation Game caroline becker avatar 1background

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