XP Game

XP Game est une simulation ludique du jeu de la planification en Extreme Programming, créée par Vera Peeters et Pascal Van Cauwenberghe. Les participants jouent successivement les développeurs et les clients autour d’histoires utilisateur matérialisées par de petites tâches physiques ou de réflexion. À chaque itération, les développeurs estiment, les clients priorisent selon la valeur et le budget de temps, l’équipe réalise, puis la vélocité réelle sert à mieux planifier la suite. Le jeu fait vivre concrètement les tensions entre ambition, capacité réelle, valeur métier et dialogue client-développeur.

Déroulé

1. 1

   Installer le cadre et l’intention

   10 à 15 min

   Accueillez le groupe et annoncez : « Nous allons simuler la planification Extreme Programming, pas en parler abstraitement. Vous allez estimer, choisir, produire, mesurer, puis réutiliser ce que vous avez appris. » Précisez que le jeu dure entre 90 et 150 minutes et fonctionne avec 4 à 24 participants. Présentez les deux rôles : développeurs, qui estiment et réalisent, et clients, qui choisissent et priorisent selon la valeur et le budget de temps. Insistez sur le droit à l’erreur : l’objectif est d’apprendre par les écarts entre prévision et réalité.

   Astuce — Dites explicitement que les estimations ne sont pas des engagements moraux : cela évite que les participants se défendent au lieu d’apprendre.

2. 2

   Présenter les histoires utilisateur et les règles du cycle

   10 à 20 min

   Montrez le stock d’histoires utilisateur : ce sont de petites tâches physiques ou de réflexion, par exemple gonfler des ballons, bâtir un château de cartes, trier des cartes ou faire des calculs. Expliquez le cycle complet : les développeurs estiment chaque histoire, les clients sélectionnent et priorisent selon la valeur et le budget de temps, puis l’équipe réalise dans un temps très court. À la fin, seules les histoires terminées selon le critère annoncé sont comptabilisées. La vélocité réelle obtenue servira à planifier l’itération suivante.

   Astuce — Avant de commencer, faites reformuler le cycle par un participant côté client et un participant côté développeur ; les malentendus apparaissent tout de suite.

3. 3

   Former les groupes et attribuer les premiers rôles

   5 à 10 min

   Répartissez les participants en un ou plusieurs groupes selon l’effectif, en gardant des équipes assez petites pour que tout le monde manipule et décide. Dans chaque groupe, désignez des développeurs et des clients pour la première itération. Annoncez que les rôles tourneront afin que chacun expérimente les deux points de vue. Donnez aux clients les informations de valeur disponibles pour les histoires et aux développeurs l’accès aux descriptions nécessaires à l’estimation. Rappelez : « Les clients maximisent la valeur, les développeurs rendent visible la capacité. »

   Astuce — Si certains profils prennent naturellement le pouvoir, placez-les d’abord dans le rôle le moins confortable pour eux ; le débrief sera plus riche.

4. 4

   Itération 1 : estimer, choisir, réaliser

   20 à 30 min

   Lancez la première estimation : les développeurs examinent les histoires et donnent une estimation de l’effort ou du temps nécessaire, sans commencer à produire. Les clients écoutent, comparent la valeur des histoires et composent un plan compatible avec le budget de temps annoncé pour l’itération. Dites : « Vous devez choisir ce qui apporte le plus de valeur dans la capacité que vous pensez disponible. » Lancez ensuite la réalisation dans un timebox très court et visible. À l’arrêt, faites poser les mains et vérifiez uniquement ce qui est réellement terminé.

   Astuce — Soyez strict sur l’arrêt du timebox : une fin floue détruit l’apprentissage sur la vélocité réelle.

5. 5

   Mesurer la vélocité et rendre les écarts visibles

   10 à 15 min

   Avec le groupe, listez les histoires prévues, celles terminées et celles non terminées. Calculez la vélocité réelle à partir du travail effectivement terminé pendant l’itération, selon l’unité d’estimation utilisée par les développeurs. Demandez brièvement : « Qu’avions-nous prévu ? Qu’avons-nous réellement livré ? Qu’est-ce qui explique l’écart ? » Notez la vélocité de façon visible, car elle devient une donnée de planification pour la suite. Ne cherchez pas encore à résoudre tous les problèmes : gardez l’énergie pour l’itération suivante.

   Astuce — Évitez le débat sur les excuses ; ramenez toujours à des faits observables : terminé, non terminé, estimé, choisi, livré.

6. 6

   Itérations suivantes : planifier avec la vélocité réelle

   30 à 60 min

   Faites tourner les rôles afin que les clients deviennent développeurs ou inversement, puis relancez le même cycle. Les développeurs estiment les nouvelles histoires ou révisent leur compréhension, tandis que les clients priorisent à partir de la valeur et du budget de temps. Cette fois, demandez explicitement d’utiliser la vélocité réelle précédente pour limiter le plan : « Planifiez avec ce que l’équipe a prouvé, pas avec ce qu’elle espère. » Lancez la réalisation, mesurez à nouveau, puis comparez la stabilité ou l’évolution de la vélocité.

   Astuce — Après un premier échec, les clients ont tendance à tout réduire ; challengez-les sur la valeur pour éviter une planification seulement prudente.

7. 7

   Débrief structuré et transfert au travail réel

   20 à 30 min

   Rassemblez tout le monde et séparez d’abord les faits, les ressentis et les apprentissages. Faites ressortir les thèmes clés : estimation, vélocité, priorisation par la valeur et relation client-développeur. Demandez aux participants d’identifier ce qui a changé entre la première et la dernière itération dans leur façon de décider. Terminez par une transposition : « Dans vos projets, quelle donnée réelle pourrait remplacer les promesses ou les opinions ? » Faites formuler une action concrète applicable dès le prochain cycle de travail.

   Astuce — Gardez au tableau une colonne “dans le jeu” et une colonne “dans nos projets” ; cela empêche le débrief de rester anecdotique.

Variantes

• Faire jouer plusieurs équipes en parallèle avec le même stock d’histoires, puis comparer les vélocités et les stratégies de priorisation sans chercher à désigner un gagnant.
• Ajouter une rotation systématique des rôles à chaque itération pour que chaque participant vive au moins une fois la tension du client et celle du développeur.
• Utiliser un jeu d’histoires préparé sur mesure avec des tâches liées au contexte de l’entreprise, tout en conservant le principe : estimation, choix par la valeur, réalisation courte, mesure de vélocité.
• Pour un format à distance, privilégier plutôt une autre simulation adaptée aux outils collaboratifs ; XP Game repose sur des tâches physiques et est donné ici comme format présentiel.