The XP Game – how to play


All participants are expected to have colored sheets of paper (preferably blue and yellow), a pen or a pencil, an eraser, some balloons, a plain paper or a notepad, three dices and playing cards.

Although the name of the game is XP game, projecting that only XP teams can play it, it is not so. Even Scrum teams or any team that uses user stories, story points for estimation and business value to determine priority, can play this game.

The XP Game is one of the best Agile games that brings out self-organizing abilities of teams, understanding of the importance of business value and estimation through story points. It also helps in understanding velocity.

This version of the game is designed for distributed teams, who work remotely, and who meet virtually through video conferencing software for their Daily Scrum/stand up, Sprint Review, Sprint Retrospective or planning meetings and who use story cards in PM tools like Trello or Jira.

There are three-four roles – the Customer/Product Owner, the Developer, the Tester and the Agile coach/Scrum Master.

The Coach runs the game.

As a coach, explain the rules and regulations of the game.

The rules are
1. A tester cannot pick any story card to work on except the Sums solutions cards.
2. A tester/customer will match the output from a dev story card with the acceptance criteria before passing the story.
3. The Coach shall not mark the story as a success if the tester has not passed the story.
4. A developer cannot pick the same story as another unless pairing is enabled in some form.
5. The coach shall provide the total estimation points for an iteration and all estimated stories picked must add up to a value less than or equal to the total estimation points for the iteration.
6. The Start timer button runs the timer for 90 minutes, with no stoppage between iterations.
7. The Coach shall start and stop the timer.
8. Since Agile is about self-organizing teams, no team member ie. developer or tester, shall modify any value of the score sheet values nor interfere with the timer.
9. The coach updates the story # and the estimate given by the team member for each story picked for the iteration in the score sheet at the end of each iteration.
10. If a story’s complexity is too high or is marked Impossible by the developer, keep the story aside for discussion with the PO/Customer. Implementation of the reworked story is not part of the game.

At the start of each iteration, the entire team is directed by the coach to read the stories,
marked for the iteration, and pick the stories with an effort estimate for implementation.
The sequence is Plan, Do, Check, Act /Adjust.
The coach shall direct the team about the total estimation points for the current iteration.
The team shall agree to the estimated complexity value.
Each team member shall turn on their video to demonstrate how they are implementing their story.
The developer shall inform the coach as soon as their story is done and the coach will notify the tester of the stories ready for testing, instantly.
The tester shall check the acceptance criteria for each story or if it is the Sums story, match the developer implementation with that of the solutions card and notify the coach if the story is passed or not.
The Customer/Product Owner can create a release plan or order the Product backlog in consultation with the coach keeping the business value of each story as the guide.
At the end of a stipulated time, as per the coach’s discretion and understanding, in each iteration, the team shall watch the demo of each story with the customer/PO approving passed stories.
Incomplete/rejected stories are marked with penalty points.
The Coach conducts a Retrospective without stopping the timer at the end of each iteration and makes note of the problems.
The Coach then makes an action plan on the problem areas and shares with the team in the next iteration.
If during implementation, there are any problems, the coach shall seek the help/guidance of the Customer/Product Owner.

Debrief points:
The coach shall
Explain how chaos could get caused if any team member modified the score sheet or the timer.
Explain how incomplete stories lessen the business value for the customer.
Explain how velocity of the team becomes clear after each iteration.
Explain how lack of full understanding or lack of knowledge of the domain impacts the Do part (ie. how to implement).
Explain the need to fully understand the story before picking for implementation.

Important points to note:
There are no missing stories.
If there are any stories that seem to be a mistake, they are not.
All Scrum events (if it is a Scrum team playing the game) must be performed within the time box planned for each iteration ie. Sprint.
At the end of the game, check if the Inspect and Adapt mechanisms worked and whether any problem/improvement areas identified by the team were addressed and improved upon.