Le Scrum@Play – règles et cartes

Lors d’un précédent meetup, j’avais présenté le Scrum@Play qui est un nouveau jeu pour sensibiliser sur le Scrum et le Story Mapping. Afin de pouvoir vous même l’animer, voici les règles du jeu de cette première version et tout le nécessaire pour imprimer votre jeu complet.

Le Scrum@Play

Le Scrum@Play se déroule en deux phases distinctes : le story-mapping et le scrum.

Préparation du matériel requis

Pour commencer, vous allez devoir imprimer le plateau de jeu ainsi que l’ensemble des cartes. Imprimez en recto-verso afin d’avoir les deux sens des cartes.

Vous n’oublierez pas de découper les cartes. Si vous avez le matériel à disposition, je vous recommande de plastifier l’ensemble des éléments.

Cartes et plateau Scrum@Play à imprimer 
Version Klaxoon à importer (de Sylvain Pichard)

Avec cela, il vous faudra trouver trois petits jetons et deux dés pour avoir un jeu complet.

* Pour simplifier l’animation, je vous conseille fortement de vrais dés et pas une application dés car le téléchargement et l’installation peuvent prendre du temps.

Lancement du Scrum@Play

Pour lancer le jeu, nous allons fonctionner par une explication incrémentale du jeu et le faire savoir à nos participants. Tout expliquer en amont peut devenir une source de confusion pour la suite.

On va disposer le plateau avec trois jetons dessus, les deux dés sur le côté, et les cartes en paquet selon leur type comme le montre l’image ci-dessous :

Le facilitareur explique que le jeu se déroulera en deux parties différentes.

Il demandera à l’équipe de déterminer qui sera scrum master et qui sera product owner. Le facilitateur profitera pour sensibiliser les participants à ces deux rôles. les autres participants seront développeurs.

Faisons un story-mapping simplifié

Lors de cette première phase de jeu, le facilitateur va apprendre aux participants à faire un story-mapping pour organiser et prioriser le travail.

Les participants prendront les cartes « Epic » et « Items » et placeront l’ensemble des cartes Items sous les cartes Epics correspondantes.

Voici un exemple sur deux « Epic » différents :

Maintenant que ce travail est fait, le facilitateur expliquera la notion de MVP (Minimum Viable Product) et proposera aux participants de séparer en deux les items.

En haut : les items obligatoires pour sortir le produit (1ère release MVP)

En bas : les items qui pourront être réalisés plus tard dans une seconde release

Les notions de priorisation comme MoSCoW ou le ROI sont volontairement pas utilisés pour rester dans un contexte simple à comprendre.

Voici le résultat sur deux Items :

Lancement d’un premier sprint

Le facilitateur va expliquer l’ensemble des éléments proposés par ce jeu de tableau.

Le plateau de jeu

Le plateau présente trois zones distinctes :

1. un cercle avec 5 cases représentant 1 sprint d’une semaine
2. un indicateur satisfaction utilisateur (on le voit juste après)
3. un indicateur motivation de l’équipe (on le voit juste après)

Le facilitateur expliquera ce qu’est un sprint et ce concept d’itération en scrum. Il rappellera que les sprint de deux semaines sont les plus recommandés mais qu’il est possible de faire des sprint de 1 à 4 semaines selon le scrum guide.

Quand le joueur termine le tour de la case 5, il ira en case 1.

Faire un petit board kanban

Pour avoir une bonne vision de l’avancement, le facilitateur va proposer aux participants de faire un petit board kanban sur une feuille A3 sur lequel l’équipe pourra disposer ces « Item » dessus.

Le facilitateur expliquera aux participants l’intérêt de ce board.

Voici un exemple simple :

Les deux dés

Les deux dés seront à jeter à chaque tour. Le total des deux dés permettront de déterminer le travail réalisable de l’équipe (soit le total de point d’effort réalisable).

Des cartes ou les deux indicateurs (satisfaction utilisateur et motivation de l’équipe) pourront jouer le total des points d’effort réalisables.

Les cartes « pré requis », « items » et « bug » sont les cartes à réaliser qui auront des points d’effort écrit dessus.

Le facilitateur profitera pour expliquer cette notion de « point d’effort ».

Satisfaction utilisateur

Ces cases vont de +4 à -4. Des actions sur les cartes viendront modifier la satisfaction des utilisateurs considérées comme essentielle dans un produit agile.

Si vous avez -2 en satisfaction utilisateur, alors il faudra enlever -2 au total des dés obtenus à chaque tour.

Si vous avez +2 en satisfaction utilisateur, alors il faudra ajouter +2 au total des dés obtenus à chaque tour.

Motivation de l’équipe

Ces cases vont de +4 à -4. Des actions sur les cartes viendront modifier la motivation de l’équipe considérées comme essentielle pour obtenir une bonne productivité.

Si vous avez -2 en motivation de l’équipe, alors il faudra enlever -2 au total des dés obtenus à chaque tour.

Si vous avez +2 en motivation de l’équipe, alors il faudra ajouter +2 au total des dés obtenus à chaque tour.

Les cartes Epic

Ces cartes ne sont plus utilisées dans cette phase de jeu. Elles permettaient de travailler sur le story-mapping.

Les cartes Item

Ces cartes sont les user-stories à réaliser lors des sprint. Elles indiquent les pré-requis obligatoires et les points d’effort nécessaires pour les réaliser.

Il est impossible de faire une carte Item si les pré-requis écrit sur la carte ne sont pas dans la case « done » (les pré-requis ont des numéros).

Voici un exemple de carte item pour bien comprendre :

Les cartes pré-requis

Ces cartes sont des non-functional requirement qui permettent de mettre en place le socle technique (certains coachs ne sont pas fan). Certains pré-requis permettent de sécuriser l’environnement et ne sont pas obligatoires.

Les participants les ont toutes de bases au démarrage du sprint.

Les cartes bug

Les cartes bugs sont à piocher que lorsqu’une action l’impose. Chaque carte bug explique les contraintes qu’elle amène que les participants devront respecter.

Les cartes action

Les participants devront piocher une carte action à chaque tour. Elle explique des évènements réels vécus par des équipes scrum et les conséquences de celles-ci.

Les cartes review et rétro

Les participants devront les piocher qu’en fin de sprint soit à la fin du tour de la case 5. Ils devront respecter ce qu’il y a écrit sur ces cartes.

Un sprint de 5 tours

Chaque sprint (itération) fera 5 tours. Les participants lanceront les dés à chaque tour et déplaceront le pion d’une case à l’autre.

1er tour

Les participants définiront ce qu’ils penseront pouvoir réaliser lors du sprint avant même de lancer les dés. Ils prendront en considération la priorisation réalisée lors du story mapping.

Les participants mettront ce qu’ils pensent pouvoir réaliser dans la colonne « Todo » du tableau kanban.

Sur le premier sprint, le facilitateur expliquera cette notion de sprint planning qui permet de démarrer un sprint et la notion d’engagement. Il pourra également expliquer cette notion de point d’effort.

Quand ce sprint planning est terminé, les participants piocheront une carte action. Ils devront la lire et respecter les actions imposées par celle-ci.

Ensuite, ils lanceront les dés pour connaitre le total de point d’effort réalisable (ne pas oublier d’enlever ou d’ajouter des points selon les cartes, la satisfaction utilisateur ou motivation de l’équipe). Ils passeront alors les cartes de « Todo » à « Done » en ne dépassant pas le total de points d’effort.

Si il reste des points d’effort pour finaliser une carte, les participants mettront la carte dans « in progress » et noteront dessus le reste à faire pour pouvoir la mettre en « Done ».

Du 2ème tour au 4ème tour

Ces tours n’ont rien de spéciaux. Il faudra commencer le tour en piochant une carte action et en lançant les dés.

5ème tour

Le début du 5ème tour est identique au précédents : carte action et lancé de dés.

Quand cela est fait, l’équipe fera une review rapide entre eux : énoncer ce qu’ils ont terminés et l’état d’avancement. Ils prendront également une carte « review » sur laquelle il y a des instructions à suivre.

Et pour finir, l’équipe fera une rétro rapide entre eux : déterminer comment on peut s’améliorer dès le prochain sprint. Ils prendront également une carte « rétro » sur laquelle il y a des instructions à suivre.

Sur le premier sprint, le facilitateur expliquera cette notion de sprint review et sprint rétrospective qui permet de terminer un sprint et la notion d’amélioration continue.

Et les autres sprint

Les participants ayant toutes les explications en main pourront faire 3/4 sprint supplémentaires à leur rythme.

Vous savez à présent tout pour animer ce jeu ludique très utile pour sensibiliser les équipes au Scrum.

Si certaines explications ne sont pas claires, n’hésitez pas à me demander et cette documentation s’améliorera selon vos différents retours.

Vérifier notre engagement

Il est intéressant de proposer un tableau simple pour comparer l’engagement de l’équipe et la vélocité réalisée en fin de sprint.

Voici un exemple de tableau simple :

Droits d’exploitation ?

Le Scrum@Play est sous licence Common Creative. Voici quelques réponses que je peux vous apporter sur le droit d’exploitation du jeu :

• Ce jeu est utilisable en entreprise sans soucis
• Ce jeu peut-être utilisé lors de vos formations (même rémunérées) sans avoir à reverser quoi que ce soit
• Toute utilisation du jeu quel qu’en soit le contexte est autorisé sans accord préalable
• Toute communication est autorisée sans accord préalable
• Il est autorisé de numériser le jeu pour vos atelier (new mai 2020)

Voilà les quelques restrictions apportées à ce jour :

• Nous bloquons le fork pour le moment afin que toute personne voulant contribuer à son évolution participe à celle-ci avec nous. (new mai 2020)
• Nous vous demandons de garder les concepts du jeu initial et les textes associés ! Cependant tout nouveau design est autorisé. (new mai 2020)
• Nous demandons à ce que le nom des auteurs soient rappelés : jeu créé par Judicaël Paquet (Myagile Partner) et amélioré pour une V1 par Dhia Eddine Ben Cheikh et Philippe Sellem.

Cependant lors des formations/workshop/meetup, si le coach veut tester quelque chose dans le but de nous offrir son feedback sur sa tentative de modifier légèrement le jeu, il est tout a fait autorisé à le faire. Le test and learn est évidement recommandé par notre équipe.