Build a single “LEGO® city” by using the Scrum framework with the collaboration of multiple development teams.
With this playful scrum simulation you:
- practice product development using a vision
- can practice with 20 people or even more
- challenge teams to work on a common goal
- enable continuous improvement
- Timebox of 2 hours
- Multiple teams of 4-6 people
- LEGO® brick set for each team
- Planning Poker cards
- Post-its, flip chart paper and markers
Make sure there is enough room and a table for each team. A separate room for building the integrated product is handy.
1. Organize into Scrum teams
Teams are self-organizing and work on the integrated product “LEGO® city”. All the students in the training must now self-organize to teams of 4-6 developers. Each team member in the teams is a developer and builds on the product.
Each team has a Scrum master who focus on the process and builds the product like other developers on the team. At this moment each team has to choose a Scrum Master.
As the trainer you are also the Product Owner.
During the game you observe the following as a trainer:
- Turn bad habits of teams into learning points for good agile adoption
- Watch out for managers, every team member has to be a developer
- Teams should be proactive, encourage this behaviour
Make sure you clarify when you are the trainer or Product Owner during the game because teams need to know how a Product Owner behaves.
2. Explain the product vision
As the trainer you need to communicate that:
- every Scrum team is working on the same LEGO® city
- there is no competition between teams
- only the Product Owner makes the decisions
- the Product Owner will be available for questions and feedback
As the Product Owner you have a clear vision about the “LEGO® city”. After all it is your city.
An example vision of the city can be explained using the following vision board:
|Vision statement: LEGO® city is a place to relax for hard working citizens and a save place for children.|
3. Build the Product Backlog
As the Product Owner you share the features of the LEGO® city with the teams using the Product Backlog. These items can be written on post-its and must be placed on a wall or flip chart paper. A Product Backlog for the example vision board consists of the following user stories:
- As a parent I want a two story building so that I can live in the city with my family
- As a citizen working outside the city I want a one story building so that I can live in the city
- As a citizen I want a shop so that I can do grocery shopping
- As a parent I want a school for my children in the neighborhood so I can meet other parents in my neighborhood
- As a believer I want a church so that I can worship together with other believers
- As a citizen I want a hospital so that I can get treatment when I need it
- As a child I want a kindergarten so that I can play with my friends from the neighborhood
- As a citizen working outside the city I want a bus stop so that I can get to my work
- As a citizen I want a roundabout so that the traffic can move through the city efficiently
- As a citizen I want a park near the river so that I can relax after work and watch the boats
- As a citizen I want the river to be a safe place for my children so that the children can play alone
- As a citizen I want a bridge over the river so that I can go to the other side of the city
The Product Owner can use the following acceptance criteria to keep the requirements transparent.
- The item must be implemented in the integrated LEGO® city
- The one story buildings and two story buildings must have the same height
- The neighborhood must be symmetrical
- Buildings must have a certain volume so they can be to high, low or too deep
- Buildings must use a specific color
Some features can be drawn on paper like the river, roundabouts and park. Let the creativity of the teams do the work.
4. Estimate the Product Backlog
For estimation the teams are going to use Planning Poker. Two complexity points are assigned to the one story building to agree on complexity as a group.
As the trainer you ask the teams to pull user stories one by one from the Product Backlog for estimation. You’re done when all the Product Backlog items are estimated.
The team can ask the Product Owner for sharing some details. These details can be written on the back of the post-its so other teams can benefit from these details during the development.
5. Sprint planning
This event is part of the actual Sprint. The game has three Sprints in total.
The trainer ask the teams to pull items from the Product Backlog to the planning wall for the current Sprint. Every team has its own column on the planning wall. Items on the planning wall is called the Sprint Backlog.
The Scrum Masters in the teams makes sure the developers on the team plan the right number of complexity points and speak out the shared commitment on the Sprint Backlog.
The number of complexity points a team plans for the sprint must be balanced between teams for the first sprint. In the second and third Sprint the complexity points can vary based on the team velocity.
|Team A||Team B||Team C|
6. Sprint development
In the development of the Sprint the Product Owner is there for questions and answers.
As the trainer make sure the time is visible in the room using a stopwatch although it is the responsibility for the Scrum Masters to coach the teams on the given timebox.
7. Sprint review
When the time is up as the Product Owner you start demanding.
“Where is my city? I need my city within three Sprints”
Items are finished when the Product Owner says there done.
Items from the Sprint Backlog are placed back to the Product Backlog by the trainer when they are not finished.
At this moment the trainer is calculating the metrics. Finished items count as velocity for the team. The total velocity is calculated for each team and is filled in on the planning wall for the current sprint.
Finally the trainer is updating a burn-down chart for the entire LEGO® city. The vertical axis is the total number of point of the Product Backlog. The horizontal axis are the three sprints.
8. Sprint retrospective
The teams can reflect to make some improvements to the process. During this Retrospective team members ask themselves what can be improved in the next iteration. The team makes a plan how to make an improvement.
The Scrum Masters makes sure that during the Retrospective nothing is build.
At this moment the next sprint is started.
9. Evaluation of the game
As the trainer run a discussion about the following questions:
- What did students observe?
- How did it feel being on a Scrum team?
- How did the Sprints go?
- How accurate were the estimations
- Was the Retrospective fruitful for the next Sprint?
- What would we have done differently from the beginning, if we had another chance to play the game?
- What was the job of the Product Owner?
- How did it feel after the first Sprint when almost all items required re-work?
- What did the Scrum Masters do?
- How will your strategy change, if you know the Product Owner is unavailable during sprints?
- How did inter-team communication go? Were there any dependencies? How were they resolved?
- What did students learn?
Based on Scrum simulation with LEGO® v2.0 written by Alexey Krivitsky
LEGO®is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this site