Guide Scrum | 25. Jeu d’estimation d’équipe

Le jeu d’estimation d’équipe est une technique facilitant la planification des sprints dans Scrum. En quoi cela diffère-t-il du Planning Poker ? Pourquoi certaines équipes de développement le trouvent-elles 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 versus Planning Poker
4. Résumé

Introduction

Le jeu d’estimation d’équipe est également appelé estimation par couloirs. Ce dernier terme est né d’une observation spontanée d’un jeu de cartes, car l’affichage des cartes ressemblait aux couloirs de natation d’une piscine.

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

Les prompts du jeu d’estimation d’équipe :

• un paquet de cartes d’histoires utilisateur – préparé séparément pour chaque jeu
• un paquet de cartes de points d’histoire – pour une utilisation répétée

Tout d’abord, empilez les cartes d’histoires utilisateur dans l’ordre correspondant aux entrées du backlog produit. Pour s’assurer que les plus urgentes soient estimées en premier.

Les cartes de score contiennent généralement des valeurs correspondant à la suite de Fibonacci. C’est une suite 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, et ainsi de suite.

Les phases du jeu d’estimation d’équipe :

1. Introduction. Pour jouer au jeu d’estimation d’équipe, les membres de l’équipe Scrum s’assoient autour d’une table. Le Product Owner commence par tirer la première carte du paquet d’histoires utilisateur et partage son contenu avec tous. Ensuite, les cartes restent sur la table. Puis le Product Owner explique au reste de l’équipe Scrum qu’à partir de maintenant, les joueurs évalueront les histoires utilisateur comme faciles ou difficiles à mettre en œuvre en les plaçant respectivement à gauche et à droite. Si l’une d’elles présente un certain degré de difficulté, le joueur les empilera ensemble, l’une sur 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 tire une carte du paquet d’histoires utilisateur. Après avoir partagé son contenu avec tous, il explique son essence au Product Owner. La personne tenant la carte la place ensuite sur la table et choisit une place en fonction de son opinion sur la difficulté de cette histoire utilisateur. Ensuite, le joueur explique le raisonnement derrière le choix à tous et les autres joueurs sont libres de poser des questions concernant le raisonnement. Ils ne peuvent pas remettre en question la décision elle-même mais les arguments justifiant la décision.
3. Maintenant, les joueurs prennent leur tour et ont deux options à choisir :
• Répéter l’étape 2, ou
• Déplacer l’une des cartes sur la table vers sa position la plus appropriée

S’ils choisissent la deuxième option, ils doivent également justifier ce qui les a amenés à changer d’avis. Les joueurs prennent des tours en répétant l’étape 3 jusqu’à ce que toutes les cartes du paquet d’histoires utilisateur soient distribuées et estimées.

4. La dernière étape de placement des cartes d’histoires utilisateur se produit une fois, ou plusieurs fois, selon la pratique de l’équipe Scrum. Au cours de ce tour, chaque joueur a encore une autre occasion de déplacer l’une des cartes sur la table vers un endroit plus approprié.
5. Une fois que les joueurs ont assigné toutes les cartes d’histoires utilisateur à leurs emplacements représentant des niveaux de difficulté, l’équipe de développement passe à l’appariement des valeurs en assignant les cartes du tas de points d’histoire. La première carte d’histoire utilisateur à gauche reçoit la carte de points d’histoire 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. Cela complète l’estimation.

Jeu d’estimation d’équipe versus Planning Poker

Le jeu d’estimation d’équipe 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 de cartes. Le jeu d’estimation d’équipe utilise la bien connue “règle de la table de cartes” des jeux de cartes populaires. Cela signifie qu’une fois que vous avez placé une carte, vous ne pouvez pas la reprendre. Comme l’histoire utilisateur est estimée par une personne à la fois, la fluctuation entre les estimations et le nombre de fois que les positions changent est significativement plus faible, par rapport au Planning Poker.
• Un calcul suffisamment précis. Dans le Planning Poker, un consensus complet doit être atteint pour chaque histoire utilisateur. Dans le jeu d’estimation d’équipe, cependant, une seule personne décide. Même si son estimation est incorrecte, un autre développeur la placera probablement en l’apparentant à sa valeur plus précisément. Cela garantit d’atteindre des estimations suffisamment précises et rapides.
• Épuisement du sujet de discussion. Les choix argumentés prennent souvent un temps excessif lors du jeu de Planning Poker. Leur temps est considérablement réduit lors d’un jeu d’estimation d’équipe car ils se concentrent sur une seule décision d’un des développeurs plutôt que sur la nature de chaque histoire utilisateur.

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 d’histoires utilisateur prévues dans un sprint donné, certains développeurs peuvent se sentir exclus.

Jeu d’estimation d’équipe – résumé

Le jeu d’estimation d’équipe a la réputation d’être la technique d’estimation la plus efficace pour la plupart des équipes Scrum. Cependant, il est important de se rappeler que c’est seulement un outil pour estimer la difficulté et l’effort des histoires utilisateur. Et comme tout outil, nous devrions l’ajuster pour correspondre aux besoins et aux capacités des membres de l’équipe.

Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.