The XP Game is a playful way to familiarize the players with some of the more difficult concepts of the XP Planning Game, like velocity, story estimation, yesterday’s weather and the cycle of life. Anyone can participate. The goal is to make development and business people work together in 1 team. It’s especially useful when a company starts adopting XP.
In real life Planning Game, development and business people are sitting on opposite sides of the table. Both participate, but in different roles. The XP Game makes the players switch between developer and customer roles, so that they understand each other’s behaviour very well.
Some of the concepts in the Planning Game are difficult to grasp, for developers and for customers. This XP Game is a practical way to demonstrate how the rules of the XP Planning Game make up an environment in which it becomes possible to make predictable plans. After all, the easiest way to get a feeling for the way it works is to see it working.
It differs from the classical Mousetrap or Coffeemaker Game in several ways. First, the developers and the customers are not separated. Second, no special skills are required in order to complete the implementation phase successfully. And finally, there’s a small element of competition in it that makes it a really fun game to play.
Addressed concepts: velocity, planning game, estimation, and how to explain these concepts in a clear way to all participants in the XP process.
Every member of the audience will participate as a teammember.
The three authors will act as coaches. If there are more than 25 participants, we will need additional coaches. Candidates can contact vera.peeters@tryx.com.
Each team receives about 10 story cards. Each card contains the following:
The team estimates how long the story will take to implement. They must choose one of 10-20-30-40-50-60 seconds or "will take longer than 60 seconds, this is too big to estimate". The team may ask the coach questions about the story. The coach should suggest that estimates be done by comparing stories. E.g. if a story is twice as difficult as another, estimate twice the time.
The team selects stories whose estimated total length does not exceed 120 seconds (the length of the iteration). The team must maximize the number of business points to earn by implementing the stories.
The team orders the stories for implementation. All the stories must be "implemented" sequentially in this order.
The stories are taken one by one. Team members volunteer to implement the story. Before implementation, the team may hold a short discussion on how best to implement the story. The team may ask the coach questions about implementation and acceptance conditions.
When a developer starts the implementation of a story the stopwatch is started. The stopwatch is stopped when the story is finished and accepted by the coach. The business points of the story are earned; the elapsed time is deducted from the total iteration time (120 seconds).
The iteration continues until the 120 seconds have elapsed. If all the selected stories have been implemented before the 120 seconds have elapsed, the team may select more stories for implementation.
At the end of the iteration, the score sheet contains the stories, estimated time and business points earned. The business points are summed. The sum of the estimates of the implemented stories is the new velocity.
The team receives a few (5-10) more story cards to estimate. This time, the coach must stress that the estimations be done by comparing with the estimates (not the actual execution time!) of the previously implemented stories. To underline this fact, we no longer speak of seconds, but of "points".
The team must choose stories for a total estimated time equal to the team velocity.
The stories are implemented one by one, until 120 seconds (the fixed length of an iteration) have elapsed. The stories, estimates and business value earned are added to the score sheets. The sum of the estimates of the implemented stories is the new velocity.
Further iterations can be done, each time selecting stories with the total estimate equal to the team velocity measured during the previous iteration.
To give the game a more "real world" sense, the game master may decide at the end of an iteration that "the specifications have changed". All stories written on cards of a certain color have no business value at all. This change retroactively applies to stories that have been implemented!
At the end of a few iterations (3 is recommended) the game ends. The team with the largest number of business points wins. If the planning game works, the teams should be able to accurately plan each iteration; they are able to implement (almost) all the chosen stories in each iteration after the first or second.
Pascal Van Cauwenberghe is CTO and co-founder of Lesire Software Engineering. He has more than 10 years of experience as a developer and architect of distributed systems. The past year, he has introduced and advocated XP in his own company, which is one of the few companies in the Benelux which applies almost all the XP practices. You can contact him at pascal.van.cauwenberghe@lesire.com.
Vera Peeters is an independent consultant who has been working as a developer in C++ and Java for more than 10 years. She has been exploring the XP practices for more than a year, and she coaches the use of the XP practices in 2 companies: Lesire Software Engineering and EuropeLoan. You can contact her at vera.peeters@tryx.com.
Martine Verluyten is a software engineer at Lesire Software Engineering with 10 years of experience, mostly in developing in C++. She currently participates in the XP project that is running at the company and helps to turn it in practice. You can contact her at martine.verluyten@lesire.com.