City Building Game

The City Building Game is an entertaining tool designed for agile coaches and trainers to help teams learn the fundamentals of agile and lean principles. Inspired by the XP Game, it was developed by Alejandra Alfonso and Emilio Gutter in 2011.

City Building Game

Learning Outcomes

Like the XP Game, the participants will practice key Agile principles, including: planning, delivering value in short iterations, backlog prioritization and team collaboration.

However, the City Building Game introduces unique elements that provide a more realistic experience. Participants will learn to collaborate in multidisciplinary teams with specialists in different roles. Additionally, the game incorporates changes in the scope, teaching Lean fundamentals such as limiting work in progress and reducing waste.

The XP Game is a game developed by Vera Peeters and Pascal Van Cauwenberghe. Learn more about it here.

Materials

Each team will need the following materials:

💡
You can adjust the color specifications of the backlog stories based on the colored glace paper sheets you were able to purchase.

Room layout

Ensure there is enough space for each team to work comfortably. Each team should have its own table for materials and workspace, along with enough chairs for every team member.

Game overview

The game consists of 4 iterations, each lasting 4 minutes. Begin by asking the audience to form groups of 4 members (with a minimum of 3 and a maximum of 5 per group). Once the groups are formed, ask each group to choose a team name—city names tend to work well.

Using the presentation slides, explain that the teams are participating in a contest, and the winner will be the team that earns the most business value. Before starting the first iteration, ask each team member to choose one single role. During the construction phase, a team member can only perform tasks within their assigned roles (e.g., someone cutting circles cannot cut triangles).

All four different roles must be assigned to at least one team member and roles cannot be changed during the game. If a team has less than 4 members, one person must assume two roles. If a team has more than 4 members, one or more roles will need to be duplicated.

When you reach the slide that explains the material specifications, inform the teams that they must adhere to these colors; otherwise, their work will be rejected. Be sure to pause the presentation here and avoid showing the next slide until you're ready to proceed.

First iteration

The teams will begin with a brief planning session where they will decide which stories to work on. Once the planning is complete, start the timer and observe how the game unfolds. In most cases, teams will likely select multiple stories and attempt to work on several simultaneously. Each participant will often focus on maximizing their individual efficiency by cutting as many papers as possible.

At the end of the first iteration, visit each team’s table and ask them to present what they have accomplished. Ignore any stories that are incomplete, whether due to missing elements or elements with incomplete pieces. For the remaining stories, check whether the color specifications have been followed and ensure the elements match the wireframes from the stories and are consistent (e.g., all trees should be of roughly the same height). Reject any stories that don't meet these criteria, and then sum up the business value of the approved stories.

Finally, ask each team to take notes on the following: planned stories, approved stories, business value delivered, and work in progress (the number of stories that were either rejected or left incomplete).

Second iteration

Before starting the second planning session, show the next slide in the presentation, which outlines the updated color specifications. Explain to the teams that they may reuse any previously cut papers and unfinished stories, as long as the stories delivered in the next iteration comply with the new specifications.

Then, begin the second planning session and iteration, following the same steps as in the first iteration.

Third iteration

Inform the teams that you’ve been advised by an Agile coach who suggested an experiment with a new rule: each team can plan as many stories as they like, but they must work on only one story at a time. Additionally, all team members must collaborate on the same story (i.e., limit the work in progress to a single story).

Start the third iteration as before.

Fourth iteration

Now inform the teams that the Agile coach has instructed them to continue limiting their work in progress (WIP). However, each team can now choose their own WIP limit. They may stick with a limit of 1 or increase it, but they must adhere to this limit for the entire iteration. The limit must also be at least half of the total number of stories they plan.

Start the fourth iteration as before.

Final Review and Debrief

Once the four iterations have ended, ask one participant from each team to come forward and draw their team's progress on a board, including their results for each iteration and final numbers (e.g., number of stories completed, business value earned, WIP, etc.). Encourage them to provide a brief explanation of their performance, and discuss how limiting the WIP helped—or hindered—them.

Finally, announce the winning team and present a small prize (a box of chocolates usually works well).

Retrospective

To wrap up the game, hold a brief retrospective and ask participants to share what they’ve learned. Encourage them to draw connections between the game and their daily work, focusing on aspects like working in teams with different roles, handling scope changes, managing work in progress, and addressing common challenges in team collaboration and delivering value effectively.

Here are a few questions to help guide the retrospective:

  • How was the collaboration within the team? Did someone take on a leadership role and direct others?
  • What was your strategy for maximizing business value? Did you estimate the complexity of the stories during the planning phase?
  • Were any of your completed stories rejected? Why did that happen? Did you pay attention to the acceptance criteria and perform any quality checks during the construction phase?
  • How did the changes in scope during the second iteration affect your work? Was all the work in progress from the second iteration wasted?
  • How did limiting the WIP help reduce waste? Was it more effective to have a limit of 1 item or did a higher limit work better?
  • How did specialization impact the workflow? Were there any moments when some team members had nothing to do because the planned stories didn't require their skills? What did you do when that happened?

Translations

You can find the materials available in multiple languages: