XP Game

XP Game is a playful simulation of the planning game in Extreme Programming, created by Vera Peeters and Pascal Van Cauwenberghe. Participants take turns playing developers and clients around user stories represented by small physical or reflective tasks. In each iteration, developers estimate, clients prioritise based on value and time budget, the team executes, and the actual velocity is used to better plan the next steps. The game concretely illustrates the tensions between ambition, actual capacity, business value, and client-developer dialogue.

Walkthrough

1. 1

   Setting the framework and intention

   10 à 15 min

   Welcome the group and announce: "We will simulate Extreme Programming planning, not just talk about it abstractly. You will estimate, choose, produce, measure, and then reuse what you have learned." Specify that the game lasts between 90 and 150 minutes and works with 4 to 24 participants. Present the two roles: developers, who estimate and execute, and clients, who choose and prioritise based on value and time budget. Emphasise the right to make mistakes: the goal is to learn from the gaps between prediction and reality.

   Tip — Explicitly state that estimates are not moral commitments: this prevents participants from defending themselves instead of learning.

2. 2

   Presenting user stories and the cycle rules

   10 à 20 min

   Show the stock of user stories: these are small physical or reflective tasks, such as inflating balloons, building a card castle, sorting cards, or doing calculations. Explain the complete cycle: developers estimate each story, clients select and prioritise based on value and time budget, then the team executes in a very short time. At the end, only the stories completed according to the announced criteria are counted. The actual velocity obtained will be used to plan the next iteration.

   Tip — Before starting, have a client-side participant and a developer-side participant rephrase the cycle; misunderstandings will appear immediately.

3. 3

   Forming groups and assigning initial roles

   5 à 10 min

   Divide participants into one or more groups based on the number of participants, keeping teams small enough for everyone to handle and decide. In each group, designate developers and clients for the first iteration. Announce that roles will rotate so that everyone experiences both perspectives. Provide clients with the available value information for the stories and developers with access to the necessary descriptions for estimation. Remind: "Clients maximise value, developers make capacity visible."

   Tip — If certain profiles naturally take charge, place them first in the least comfortable role for them; the debrief will be richer.

4. 4

   Iteration 1: estimate, choose, execute

   20 à 30 min

   Launch the first estimation: developers review the stories and provide an estimate of the effort or time required, without starting to produce. Clients listen, compare the value of the stories, and compose a plan compatible with the announced time budget for the iteration. Say: "You must choose what brings the most value within the capacity you believe is available." Then start the execution in a very short and visible timebox. At the stop, have participants put their hands down and check only what is actually completed.

   Tip — Be strict about stopping the timebox: a vague end destroys learning about actual velocity.

5. 5

   Measuring velocity and making gaps visible

   10 à 15 min

   With the group, list the planned stories, those completed, and those not completed. Calculate the actual velocity based on the work actually completed during the iteration, according to the unit of estimation used by the developers. Briefly ask: "What did we plan? What did we actually deliver? What explains the gap?" Note the velocity visibly, as it becomes a planning data point for the future. Do not seek to resolve all issues yet: keep the energy for the next iteration.

   Tip — Avoid debating excuses; always bring it back to observable facts: completed, not completed, estimated, chosen, delivered.

6. 6

   Subsequent iterations: plan with actual velocity

   30 à 60 min

   Rotate roles so that clients become developers or vice versa, then restart the same cycle. Developers estimate the new stories or revise their understanding, while clients prioritise based on value and time budget. This time, explicitly ask to use the previous actual velocity to limit the plan: "Plan with what the team has proven, not with what it hopes." Start the execution, measure again, and then compare the stability or evolution of the velocity.

   Tip — After an initial failure, clients tend to reduce everything; challenge them on value to avoid overly cautious planning.

7. 7

   Structured debrief and transfer to real work

   20 à 30 min

   Gather everyone and first separate facts, feelings, and learnings. Highlight key themes: estimation, velocity, prioritisation by value, and client-developer relationship. Ask participants to identify what changed between the first and last iteration in their decision-making. Conclude with a transposition: "In your projects, what real data could replace promises or opinions?" Have them formulate a concrete action applicable from the next work cycle.

   Tip — Keep a column on the board for 'in the game' and a column for 'in our projects'; this prevents the debrief from remaining anecdotal.

Variants

• Have multiple teams play in parallel with the same stock of stories, then compare velocities and prioritisation strategies without seeking to designate a winner.
• Add a systematic rotation of roles at each iteration so that each participant experiences at least once the tension of the client and that of the developer.
• Use a custom-prepared story game with tasks related to the company's context, while maintaining the principle: estimation, value-based choice, short execution, velocity measurement.
• For a remote format, prefer another simulation adapted to collaborative tools; XP Game relies on physical tasks and is presented here as an in-person format.