LEGO Scrum is an engaging workshop in which people that are new to Scrum learn some techniques and find reasons for Scrum ceremonies. Participants build a LEGO city while experiencing Scrum ceremonies and practices firsthand. This workshop helps newcomers understand Scrum concepts in a fun, practical way.
Pre-game requirements
- Time: 120 minutes (2 hours)
- Team Size: 4-6 participants
- Materials Needed:
- LEGO set (minimum 200 pieces)
- Sticky notes and markers
- Planning poker cards
- Whiteboard or flip chart
- Timer or stopwatch
Workshop Agenda
The game will last approximately 2 hours and will follow this agenda:
- Introduction & Overview (10 min)
- Building the Backlog (15 min)
- Estimating (30 min)
- First Sprint (Timeboxed to 15 min):
- Sprint Planning (3 min)
- Sprinting (7 min)
- Sprint Review (5 min)
- Second Sprint (15 min)
- Third Sprint (15 min)
- Debrief & Retrospective (30 min)

Introduction
Before starting the game, explain the following to the group:
- Objective for the team is to deliver (build) a single product — a LEGO City. They need to work together to complete it.
- The main building material is LEGO bricks, but the team can introduce other materials as needed (paper post-its for roads or parks).
- Your role is the Product Owner. You are the primary decision-maker for the product — the LEGO City. You will define the requirements, but you may also make some Scrum-related mistakes, as you are a novice Product Owner.
- You will provide ongoing feedback and clarification, but there will be no Scrum Master to guide the team. The team must coach themselves and may convince someone to step in as a Scrum Master if necessary.
Building the LEGO Scrum Backlog (15 min)
Start by presenting the product vision to the team. You can create a visual product backlog by displaying notes with features for the city. Here’s an example of a backlog we use on our workshops:
- One storey buildings (5 items)
- Skyscraper (3 items)
- Shop
- School
- Church
- Hospital
- Bus stop (2 items)
- Road (can be drawn)
- Park (can be drawn)
- Bridge
- Military base (this item will be introduced in the Sprint 3 planning)
Prepare a Burndown Chart on the whiteboard to track progress, and set up a Kanban board with columns: To Do, In Progress, and Done.
Estimating (30 min)
Allow the team to spend 30 minutes estimating the backlog items.
Encourage the participants to estimate each backlog item using any estimation technique they are familiar with. For this type of estimation Planning Poker or T-Shirts estimation will be the best.
During this session, participants will determine how much effort each task requires. Ensure that they understand the importance of accurately estimating work for better Sprint planning. Once complete, have the team review their estimates together.
Sprints
The game consists of three Sprints, each with three key checkpoints:
- Sprint Planning (3 min): In this phase, the team chooses which items from the backlog they will work on in the current Sprint. They move these items into the To Do column on the Kanban board.
- Sprinting (7 min): The team now has 7 minutes to build the selected items. It’s a short amount of time, but enough to create several tangible pieces of the city. Use a visible countdown timer to keep everyone on track.
- Sprint Review (5 min): When the time is up, the team stops building and the Product Owner (you) reviews the completed work, starting with the words: “Where is my city?”🤓. Evaluated each item to see if it meets your acceptance criteria. Be critical but constructive:
- Does the building match the requested size, symmetry, and style?
- Are the colors and proportions consistent?
First Review – “Hardlanding” (15 min)
Usually in the first sprint, everyone is building an item on their own, a lot get built and before the review the team thinks its easy-peasy workshop.
Make them sweat!
On the first review it’s good to only accept few items and move the most to the TODO column. Don’t be afraid of nitpicking, you can make a use of my favorite approaches.
- I like the symmetry. This building is not symetric.
- I like one color buildings. This is to colorful (or invert if needed).
- Where are windows / doors in this building?
- Why those two are not in the similar scale?
The reason for such mean behavior as a product owner is to push the team to:
- ask you how do you like the buildings DURING the sprint (not at the review)
- ask details about the tasks (size, color)
- focus on fewer more important things
Second Sprint – “Improvement” (15 min)
Before starting the Sprint, move unfinished items back to the Backlog for future work. Also, update the Release Burndown Chart to reflect the current progress, and discuss the Sprint’s forecast — how much work remains and whether the team is on track to complete the city in 3 Sprints.
During this sprint, the team should do way better.
They probably clarified the “Acceptance Criteria” of buildings. They probably eliminated impediments and are delivering high-quality buildings.
Tip! If you feel team can handle that – free to announce that you are going on important meetings with LEGO investors, and leave the room for few minutes during “sprinting”.
Third Sprint – “Final fight” (15 min)
In the third Sprint, the team should be working at a much faster and more efficient pace.
If the teams performs well – then on the planning introduce an urgent new feature – military base! Briefly explain that Zombie apocalypse is coming, so the City without the base is no good.
If the team struggles, dont add new items, but instead help them scope the remaining items and maybe agree to remove few from the Backlog.

LEGO Scrum Release and Debrief (30 min)
Once the third Sprint concludes, it’s time to reflect on the game and discuss the overall experience.
Review the Burndown Chart: Assess how much work remains and how accurately the team estimated their capacity.
Debrief: Engage the team in a retrospective discussion to capture insights on the following topics:
- Observations: What did participants learn about Scrum and the Scrum ceremonies?
- Time Management: Which tasks took longer than expected? Which tasks were completed faster?
- Estimations: How accurate were the team’s initial estimates? Did they learn any lessons for future estimation?
- Product Owner’s Role: How did the team feel about the Product Owner’s decisions and feedback?
- Sprint Deliverables: How did it feel to not deliver everything planned in a Sprint? How did they manage unfinished work?
- Need for a Scrum Master: Do they think a Scrum Master would have been helpful? If s, in what capacity?
- Key Takeaways: What did they learn about Scrum, teamwork, and the process of building a product?
Conclusion and resources
The LEGO Scrum workshop is a fun, interactive way to introduce participants to the Scrum framework. By simulating the building of a city with LEGO blocks, participants get a hands-on understanding of Scrum practices such as Backlog Management, Sprint Planning, Estimating, and Reviewing. The retrospective at the end allows participants to reflect on their performance and identify areas for improvement in future Sprints.
Workshop structure ist good but timeboxes are too short for proper Deutsche quality – suggest minimum 25 minutes per sprint.
Danke!
Ran this workshop with my team last month – the ‘mean PO’ approach in Sprint 1 really opened their eyes! One tip though: have extra LEGO pieces ready. We had some creative developers who wanted to add details like streetlights and trees, and ran out of smaller pieces. The military base surprise in Sprint 3 is brilliant for teaching adaptability 😄
Great to hear that Sarah!
Very interesting workshop we did with development team in Lagos office. Not perfect first sprint because everyone was building separate parts without coordination – but after Product Owner reject most items team started working together more smart. Good learning especially about asking questions during sprint not waiting for review. Only suggestion is maybe need more clear explanation at start about acceptance criteria because some people got confused. Will definitely use this method again for new scrum teams
You are right about the acceptance criteria, but thats also the point of the game. Learning people to NOT assume but ask.