Let’s Scrum Together

Introduction
Scrumble est un jeu qui modèle les rôles, les événements et les artéfacts de Scrum. Il a pour buts de
présenter les opérations et les préceptes de Scrum à une équipe qui désire se développer autour de
ce framework.

Le jeu permet, dans une atmosphère relaxante, de mettre en lumière de nombreux problèmes
auxquels les équipes sont confrontées et de trouver dans le même temps des solutions de manière
spontanée.

Aperçu du jeu
Le plateau se compose de la manière suivante (de l’extérieur vers l’intérieur)

- En Jaune, deux cercles pour les tâches

- En vert, un cercle pour les points de la dette technique
- Au centre en gris, les différentes phases représentées par les jours (1-9), la revue, la
rétrospective et le planning

Page 2
Différentes cartes

Les User Stories à réaliser

Ainsi qu’un certain nombre de marqueurs sous forme de jetons

- Marqueur d’équipe
- Marqueur de la dette technique
- Marqueur d’une User Story

Les rôles dans le jeu

Scrum Master
Le Scrum Master est le maître de jeu. Il ne participe pas activement en tant que joueur au sein de jeu
mais son rôle est vital puisqu’il conduit les activités et facilite les décisions aux moments clés.

Product Owner
Le Product Owner est responsable pour le produit. Son rôle est de se concentrer sur la valeur
délivrée ainsi que comme personne référente en ce qui concerne le domaine d’activités pour lequel
le produit est conçu.

Membre de l’équipe de développement

Testeur, analyste, développeur junior ou expérimenté, administrateur système, graphiste, … Tous
sont égaux au sein de l’équipe (dans la vraie vie de Scrum et dans le jeu). Ils s’autoorganisent et
contribuent au développement et à l’incrément du produit durant les diverses phases.

User stories
Les User stories représentent les éléments à développer

Page 3
Une User Story comporte

- Un numéro d’identification (En haut à gauche)

- Une dépendance à une autre User Story (En haut à droite)
- Une description As [Who] I Want [What]
- Une valeur pour le Business, respectivement pour le Product Owner (En bas à gauche)
- Une taille en termes de complexité de développement (Voir plus bas)

Phases du jeu
Initialisation du jeu
- Placer le marqueur de l’équipe sur 0
- Mélanger les cartes Problem, Daily, Review
- Placer le marqueur de la dette technique sur 15

Pre-Sprint
Le Product Owner présente le produit que l’équipe va développer basé sur le scénario choisi.

Le Product Owner est la seule personne qui donne la vision du produit et les éléments du Backlog
ainsi que l’ordre des User Stories à réaliser.

Le Backlog est le container de toutes les User Stories pour les Sprints

Il est important que les participants connaissent les idées et le thème du produit pour s’assurer leur
participation.

Une fois l’ensemble des User Stories présenté et compris, les membres de l’équipe doivent estimer la
complexité relative (la taille) pour chaque User Story à implémenter.

Il faut garder en mémoire que l’estimation exacte d’un effort et de la charge de travail n’est jamais
possible. Tous les êtres humains, sont par nature, mauvais dans l’estimation absolue.

Le fait d’exécuter les User Stories sous forme de Sprint réduit généralement l’erreur et offre la
place à l’auto amélioration.

La notion de taille de T-Shirt facilite le classement des User Stories par taille

Page 4
Les Users Stories sont classées par l’équipe, priorité au sein de chaque taille en fonction de leur
valeur.

Sprint
Dans un ordre chronologique le sprint se compose

- D’une session de planification (Sprint Planning)

- De neuf jours de développement (neufs tours)
- D’une session de revue
- D’une session de rétrospective.

Sprint Planning
Le Product Owner choisit en fonction des priorités et de la valeur la plus élevée qu’il désire les Users
Stories, ainsi que les éventuelles User Stories dépendantes (dépendance en haut à droite de chaque
User Story) que l’équipe va devoir réaliser dans le Sprint.

Les User Stories choisies forment le Sprint Backlog et sont l’objectif du Sprint.

L’équipe calcule alors le nombre de tâche à réaliser pour compléter chaque User Story à l’aide de la
formule basée sur la dette technique ainsi que du nombre de membres du team.

Exemple : Une équipe de 5 personnes ayant une tâche de complexité M et une dette technique Low
 (Low x 3-M) == 12x5 = 60 tâches.

L’équipe notera sur un sticker, pour chaque User Story, le nombre de tâches à réaliser pour la User
Story et la couleur d’un marqueur qu’elle place sur le plateau de jeu, sur la case correspondant au
nombre de tâches à réaliser.

Page 5
Si le nombre de tâches à réaliser excède 100, placer plusieurs marqueurs de la même couleur,
l’équipe devra ensuite tous les collecter.

Une tâche sera considérée comme réalisée lorsque le marqueur de l’équipe atteindra le marqueur
correspondant à la User Story.

Jours de développement (Day 1  Day 9)

Chaque membre de l’équipe, hormis le Product Owner et le Scrum Master lancent un dé à tour de
rôle pour, à choix

- Exécuter une tâche

- Diminuer la dette technique

Le choix doit être évoqué avant de lancer le dé. Ce choix est à la libre discrétion du joueur en
fonction de ce qu’il considère apporter le plus de valeur au sprint ou au produit.

Si le joueur décide de réduire la dette technique, il déplacera le marqueur en arrière, en diminution,

correspondant au nombre de points indiqué sur le dé. Si le joueur décide d’exécuter une tâche, il
déplacera le marqueur de l’équipe en fonction du résultat indiqué par le dé.

Si le dé indique les valeurs suivantes

- Le dé indique 1, le joueur comptabilise le point et relance le dé pour une deuxième chance

- Le dé indique 6, le joueur pioche une carte  Problem, lit cette dernière à haute voix pour
l’équipe et effectue l’action indiqué sur cette dernière. Le marqueur n’est pas déplacé.

La carte  Problem est généralement une complication dans le jeu. L’équipe agit ensemble pour
résoudre la difficulté, pas uniquement le joueur qui a pioché la carte.

Une User Story est complétée

Une User Story est considérée comme complétée lorsque le marqueur de l’équipe atteint ou dépasse
le marqueur (ou tous les marqueurs) de la User Story. La User Story est marquée comme réalisée et
le marqueur de l’équipe est placé sur 0 (ou sur la différence de points obtenus en sus) pour
commencer une nouvelle User Story.

Lorsqu’un tour est terminé (tous les joueurs ayant lancé les dés), on passe au jour suivant jusqu’à
la revue.

Daily
A chaque nouveau jour, mis à part le jour 1 ou lors de la Review, un joueur pioche une carte Daily et
en fait part au Team.

Il n’y a plus de tâche en jeu

Si l’ensemble des tâches sont réalisées avant le jour 9, l’équipe choisit une des trois options

- Ajouter une ou plusieurs User Stories au Backlog du Sprint courant. Cela ajoutera de la
valeur livrée au Sprint.

Page 6
 - Payer la dette technique
- Finir le Sprint. Cela n’est possible que s’il n’y a plus de User Story dans le Backlog du produit.
Rendez-vous ensuite directement à la dernière Review

Sprint Review
Lorsque la revue est atteinte le Product Owner inspecte les User Stories réalisées pendant
le Sprint et calcule les scores

Il félicite, encourage et donne des conseils constructifs à l’équipe (max 5 minutes)

Le Product Owner pioche une carte Review par User Story complétée pendant le sprint

User Stories non-complétées

Les User Stories non-complétées, pour cause de dette technique ou d’autres activités sont revues et
replanifiées. L’équipe reçoit un malus sous la forme de points dans la dette technique. 1 point de
dette technique pour chaque lot de 5 tâches non réalisées.

La User Story commencée est diminuée du nombre de tâches déjà réalisées pour le prochain Sprint,
le marqueur de la User Story est placé au nouvel endroit sur le plateau.

Les Users Stories sur le plateau du jeu ne sont pas affectées par la nouvelle dette technique.

Sprint Rétrospective

Le marqueur est déplacé sur Sprint Rétrospective

Ce moment est réservé à chaque joueur pour exprimer ce qu’il a aimé (I like), ce qu’il n’a pas aimé (I
dislike) ou ce qu’il voudrait (I would like) pour le sprint suivant. (max. 2 minutes par participant)

Dans le réel, cette phase est la plus importante puisqu’elle permet d’échanger, de s’améliorer et de
s’approcher de plus en plus des principes Agiles. Il s’agit de la partie la plus formatrice de la phase.

http://agilemanifesto.org/principles.html

Le Sprint est maintenant terminé. Retour à la phase Sprint Planning

Page 7
La dette technique, votre pire ennemi
La dette technique est votre pire ennemi, elle est partout et sous toutes les formes

Le cauchemar de beaucoup de Scrum Masters est la dette technique. Quelle soit explicite ou non,
elle représente un dû envers les utilisateurs ou les parties prenantes.

La dette technique impacte le jeu à différents moments, par exemple lorsqu’il y a des tâches
inachevées à la fin d’un sprint.

Résumé d’impacts de la dette technique

La dette technique a une limite à 49. A ce niveau la situation est ingérable, espérons que vous
pourrez l’éviter

Fin du jeu
Le jeu se termine après la dernière rétrospective ou si l’équipe se retrouve confrontée à des
difficultés insurmontables.

Le score final peut être calculé pour le fun mais il ne s’avère pas le plus important. Ce qui a été appris
durant ces quelques heures est la vraie valeur du jeu. Vous pourrez alors appliquer cela aux
nouveaux projets ou aux projets en cours.

Page 8
Résumé des activités

Sprint Planning
- Le Product Owner indique les User Stories à réaliser pour former le Sprint BackLog
- L’équipe calcule en fonction de la dette technique et du nombre de membres, le nombre de
tâche à réaliser pour chaque User Story

- Chaque User Story est placée avec un marqueur sur le plateau de jeu
- Le marqueur de l’équipe est positionné sur 0.
- Le jeu commence

Day 1
- Chaque joueur choisit (Payer la dette technique, Exécuter les tâches) et lance le dé

Day 2  Day 9
- Piocher une carte Daily
- Chaque joueur choisit (Payer la dette technique, Exécuter les tâches) et lance le dé

Sprint Review
- Le Product Owner calcule les scores

- Le Product Owner pioche une carte Review par User Story complétée pendant le sprint
- Le Product Owner calcule les malus pour les User Stories non-complétées. 1 point de dette
technique pour chaque lot de 5 tâches non réalisées.

Sprint Rétrospective
- Discussion entre les participants (I like, I dislike, I would like)

Page 9
Que faire
Une User Story est complétée
Une user story est considérée comme complétée lorsque le marqueur de l’équipe atteint ou dépasse
le marqueur (ou tous les marqueurs) de la User Story.

La User Story est marquée comme réalisée et le marqueur de l’équipe est placé sur 0 pour
commencer une nouvelle User Story.

Il n’y a plus de tâche en jeu

Si l’ensemble des tâches sont réalisées avant le jour 9, l’équipe choisit une des trois options

- Ajouter une ou plusieurs User Stories au Backlog du Sprint courant. Cela ajoutera de la
valeur livrée au Sprint.
- Payer la dette technique
- Finir le Sprint. Cela n’est possible que s’il n’y a plus de User Story dans le Backlog du produit.
Rendez-vous ensuite directement à la dernière Review

User Stories non-complétées lors de la review

Les User Stories non-complétées, pour cause de dette technique ou d’autres activités sont revues et
replanifiées. L’équipe reçoit un malus sous la forme de point dans la dette technique. 1 point de
dette technique pour chaque lot de 5 tâches non réalisées

La User Story commencée est diminuée du nombre de tâches déjà réalisées pour le prochain Sprint,
le marqueur de la User Story est placé au nouvel endroit sur le plateau.

A propos
Scrumble a été créé par Pyxis Suisse en 2014 par l’esprit capricieux de Romain Trocherie, Coach Agile
et Scrum Master chez Pyxis Suisse.

Cette version des règles se base dans la majeure partie des cas se base sur celles fournies par Pyxis
Suisse. Certains points ont été simplifiés et reformulés pour une meilleure compréhension suite aux
expériences dans les divers ateliers.

La version originale et l’ensemble du matériel est disponible à l’adresse : http://scrumble.pyxis-

tech.com/index_fr.html

Page 10