The LeSS City Guide Simulation is an interactive, hands-on activity designed to help participants experience the dynamics of multiple teams working together on a single product.
In this updated version of the Nexus Zoo simulation, the focus is shifted to a practical project: creating a city guide for the city where the training is taking place. Unlike the Nexus Zoo simulation, this exercise incorporates events typically seen in LeSS adoptions, such as a Self-Design Team Workshop and Multi-Team Refinement, to better simulate LeSS dynamics.
This activity helps participants understand how multiple teams collaborate to achieve a shared product goal, offering insights into the challenges of scaling Scrum.
It is usually conducted before introducing the events in LeSS to highlight the differences between LeSS and Scrum.
Materials Needed
To run the LeSS City Guide Simulation, you will need the following:
Colored voting dots (green, red, blue, yellow)
Large post-its
Colored A4 paper
Pens and markers
Transparent binder and puncher
Stopwatch or timer
Step 1: Self-Design Team Workshop
The simulation begins with a Self-Design Team Workshop, where participants form their own teams. The trainer provides colored voting dots representing key skills needed for the work:
Green Dot: Good knowledge of the city
Red Dot: Good drawing skills
Blue Dot: Beautiful handwriting
Yellow Dot: Tripadvisor on the phone
Each participant selects dots corresponding to their skills, making them visible on their name tag. Teams are then formed with 4-5 people, ensuring a balanced mix of skills across all teams.
Step 2: Multi-Team Product Backlog Refinement
Once teams are formed, the Multi-Team Product Backlog Refinement event begins. The Product Owner (PO) — who could be the trainer or, preferably, a co-trainer — presents the product goal: creating a local city guide and getting feedback on it as soon as possible. The initial items for refinement include:
Cover Page
Must-See Attractions
Museums
Restaurants
Hidden Gems
Current Events
The PO uses large post-its for each of these items, presenting them in the order above. Items are distributed for refinement, with one item given to a group of 3-4 participants, which should be a mixed group across teams.
The goal of each group during refinement is to create:
A suggested list of items (e.g., top 5 attractions)
A layout of the page (what it should include and where - eg. drawing of the attraction, map, etc.)
After a time-boxed refinement session, all participants walk around the room, and each group presents their work. A second round of refinement may follow to add further details if needed.
At the end of the Multi-Team PBR, the PO collects the post-its with the most interesting items (e.g. Must-See Attractions, Museums) to create the backlog.
Step 3: Definition of Done (DoD)
The Product Owner presents the Definition of Done on a flipchart or large post-its, covering the following:
One page per item
No two consecutive pages of the same color
One integrated product
One common copyright at the bottom center of each page
Clear handwriting; no grammar mistakes
Step 4: Sprint Planning
Sprint Planning follows, during which the PO presents the top backlog items and asks which team will take each item, one by one. The list will usually look like this:
Cover Page
Must-See Attraction 1
Must-See Attraction 2
Museum 1
Museum 2
Must-See Attraction 3
Museum 3
The teams take as many items as they think they can complete in the given time for the Sprint.
Step 5: The Sprint
The Sprint starts, and the facilitator sets a visible timer. Teams use the time to complete an increment that meets the Definition of Done. The facilitator and/or PO should stay available to answer questions but avoid interfering unless needed.
Step 6: Sprint Review
When the Sprint ends, the Sprint Review takes place immediately, during which the completed work is inspected. The trainer sets a timer to keep the Sprint Review concise.
Step 7: Team and Overall Retrospective
After the Sprint Review, each team holds a Team Retrospective to discuss what went well and what could be improved. Afterward, the entire group participates in an Overall Retrospective, which includes the PO. This retrospective focuses on systemic improvements for the next iteration.
Common Challenges and Learning Opportunities
The simulation reveals several typical challenges, especially in the first iteration:
Lack of Communication with the PO: Teams often do not ask the PO questions about the product, such as the city guide title or copyright. In LeSS (like in Scrum), the PO is accountable for maximizing the value of the product resulting from the team’s work and should involve the team in product decisions while retaining authority over key decisions.
No Integrated Product: Participants often miss the tools for integrating pages (e.g., puncher and binder) and usually just present individual pages. In LeSS, it is important to have an integrated product that is handed over to stakeholders (e.g., customers) at the end of the Sprint.
Delayed Integration: Teams often integrate their pages into the binder only at the end of the Sprint, rather than continuously as pages are completed. In LeSS, continuous integration is encouraged to avoid last-minute issues and increase learning by observing what other teams are doing.
Insufficient Communication Between Teams: Teams often struggle to coordinate on items that should be consistent across all pages (e.g., copyright). In LeSS, team members are encouraged to coordinate directly by walking over and discussing whenever needed.
Unfinished Pages: If pages are incomplete at the end of the Sprint (e.g., drawing is not finished), the PO may add these items to the backlog for the next iteration.
Step 8: Debrief
The simulation usually involves at least one more iteration to allow teams to apply their improvement strategies and learnings. At the end of the simulation, a debrief session takes place to highlight key takeaways. Common debrief questions include:
What differences do you see between Scrum and the way you worked in the simulation?
What worked well in terms of communication between teams? What challenges did teams face in coordinating with each other? How did you ensure consistency across different pages?
How did delayed integration affect the final product?
This section provides helpful tips for facilitating different parts of the simulation to ensure a smooth and effective learning experience.
Multi-Team Product Backlog Refinement (PBR): The PO should offer one item at a time (one item for a group of 3-4 people). Teams sitting at their team tables should decide how to split into different refinement groups. The PO can answer questions about what should be done but should not be overly involved in discussing details.
In order for the PO to easily create the backlog at the end of the PBR, distribute large post-its and ask the teams to use them for the suggested attractions, museums, etc.
Sprint Planning: Ensure that instead of one team picking similar items (e.g., two museums), those items are distributed across multiple teams to promote cross-team learning and adaptability.
Sprint Execution: As a facilitator and/or PO, provide honest feedback on participants’ work but avoid giving direct guidance on how to proceed. Instead, encourage participants to think for themselves. For example, when asked about specific product details (e.g., copyright), respond with questions that prompt participants to come up with their own solutions. If asked how to coordinate that every team uses the same copyright, say, “I don’t know. What do you think?”
The LeSS City Guide Simulation provides an engaging, practical way for participants to understand the challenges and dynamics of multi-team Scrum, focusing on collaboration, handling dependencies, and continuous improvement.
RSS feed