The document proposes using LEGO bricks to simulate scrum processes like backlog creation, estimation, sprint planning, and retrospectives. It outlines how to structure a LEGO scrum simulation with a sample backlog, estimating stories in points, committing to sprints, and demonstrating increments. The simulation aims to better illustrate scrum concepts like iterative development, cooperation over competition, and challenges like dependencies. Debriefing after each "sprint" provides opportunities for valuable lessons around concepts like velocity, refactoring, and inter-team coordination.

1. www.scrumguides.com
LEGO for extended SCRUM simulation
Alexey Krivitsky, Feb 2009
alexey@scrumguides.com

2. Scrum simulation: looking for better games
Over the last couple of years I’ve participated in and facilitated several CSM classes run by different
trainers. All of those classes had different simulation sessions but I always felt like there should be better
ones.
Problems with some of the known games that I saw are:
1. Pre-prepared backlogs?
To me, backlog is an excellent tool for collecting and discussing ideas that foster creativity. The
backlogs are usually prepared by the trainer, printed on paper and handed out to the teams. Where
were the creativity part of it? Do this, then to that. It is like a commanding.
A mixed message to the Scrum newbies who have just (maybe) started to get why command and
control is not always good?
2. What were we trying to build?
In the backlog sometimes I see tasks to accomplish, not parts that make up a product. What will
those tasks result in (when are accomplished)? Usually a big mess in the class room (smile).
A mixed message to product development team?
3. Competing teams?
Usually there were like 20 people in the class. So we help split the crowd into smaller teams so
they had more fun playing the game. And of course each team in the end was competing to earn
more score than the others.
Aren’t we all talking a lot about building cooperative environment. A mixed message?
4. The metrics?
During the planning cycles of the game, the teams were asked to estimate the backlog items. So
they did. We asked them to keep track of their planned and observed velocity. So they did. But it
seems to me the only thing they cared about was the score. They apparently didn’t apply velocity
to plan releases nor they used it to double check their sprint plan. So they did it just because we
asked them to keep track of the velocity. Not because they felt any need in it.
Sounds like useless reporting to upper management (trainer in this case). A mixed message?
There are probably more things to be pointed out. And of course those games have lots of great points! I
just think there should be other games that illustrate better the things we try to teach. Hence I started to
think of better simulations and have come across the idea of using LEGO bricks (thanks to William
Wake, Jurgen De Smet, Yves Hanoulle, Mykola Gurov and other folks for opening my eyes!)
The LEGO Scrum simulation
Now after I’ve tried the LEGO Scrum simulation with different people and different cultures for several
times I can say it seems to be more consistent with what I actually try to teach. Debriefing (you play
games to debrief, right?) opens up a lot (and I mean really a lot) of nice discussions and brings bright
insights to the folks.
2

3. How we play the game
The Backlog
I tried with the following backlog and it worked fine, though it will depend on your LEGO kits and
imagination. Explain any details of the items only if you’re asked, otherwise don’t accept the item until
properly (re)done.
One-story building
You can have as many as you want in the backlog.
Two-story building
Church
A building made from bricks of one color that is a
little higher than a one-story building and with a
white cross on the top.
Kiosk
A small building with a shop assistant inside where
you can buy small stuff like chewing gum.
Kindergarten
A building with a fence so that kids don’t run away.
Lorry
You will find instructions on how to build this and
other machines in your LEGO manuals.
Loader
Tower crane
Tractor
Garage for lorry
A simple garage where a lorry can fit it – acceptance
criteria. I usually prioritize garages higher than the
machines they should hold and will gently lead the
folks to convince their PO that in order to
demonstrate this item they need to build a machine first, hence helping the PO adjust priorities to
get better products.
Garage for tractor
A simple garage where a tractor can fit in – acceptance criteria.
Bus stop
“As I a bus passenger I can wait for my bus for quite a long time and in bad weather”. This
implies having a bench and a roof.
Some of the items can be found in the LEGO instructions, some cannot. Which I believe is quite OK. For
some features you can have detailed requirements from external parties, for some you don’t. So folks just
have to ask questions to the PO (isn’t it what we want to teach them in the end?). If they don’t ask
questions they can never get stuff like a bus stop accepted.
The game is structured as a normal Scrum project according to the following cycle:
1. discussing project vision and the initial backlog
2. backlog estimation
3. backlog (re)prioritization
4. release planning
5. sprint planning
3

4. 6. sprinting (so far we needed 3 sprints each time we played)
7. demonstration
8. retrospective
9. (the cycle repeats until you run out of bricks, time or the backlog)
Visioning
During this discussion I (as a PO) bring in a context: they all work for a big company with multiple
teams involved and they are to build a city (a single product!). It is up to them to decide how to split into
teams.
Estimations
They all act as one team (20 people can do that) and they need to estimate the backlog. They have their
decks of planning poker cards and they have already practiced story point estimation by this time.
What we want them to do is to estimate as fast as they can,
but all the backlog items should be estimated in the same
units so that we can have an integrated release planning.
After some discussion they pick up a unit (a one-story
building sounds like a good unit, say 2 points) and start by
estimating the first 3-5 items together. After they all have
the idea of the size and some estimated items for future
triangulation we ask them to split into sub-teams and
estimate the rest in parallel.
Once a team gets a new item estimated they stick it to the
wall into a corresponding column (by points) so that other
teams have more data for triangulatios. So far this worked
just nice.
They can also prototype as much as they want (within the timeframe), but before the sprint starts all
prototypes have to be disassembled (we discuss the value of throw-away prototypes).
Re-prioritization
After estimations are done as a PO I usually make small changes in the priorities (estimates can affect
business decisions, otherwise why to estimate?).
Release planning
The goal is to have a big visible release burn-down chart so that all people understand where they are in
the release and what the overall progress is. After the estimation session we put a first dot on the chart
and start a sprint planning session.
Sprint planning
4

5. We’d like to coach people working in multi-team environments on how to plan sprints. So we place a
single product backlog on the wall (one sticky
per item) and flip-chart sheets for sprint
backlogs (one per sub-team).
A timer starts (we set it for 5 minutes) and the
sub-teams need to parse the product backlog by
moving items onto their team’s sprint backlog.
This goes until teams cannot commit to any
more items (we learn commitment-based
planning)
One trick to mention here is that we have two
sets of LEGO and each set can produce different
machines (lorries, tractors, tower cranes, etc.).
Which simply means that neither team that can
build everything. This basically affects their
sprint planning and, say, a lorry will show up on
one team’s sprint backlog, while a tractor on the
other’s. They are not allowed to exchange
LEGO bricks during the game so they need to
identify such constraints and dependencies
during planning (which I believe is a good skill
to learn).
Sprint planning is the right time to discuss
acceptance criteria, so when they choose to build
a garage we ask them how would they go about
demonstrating it. Probably they will have to build the machine first (this might make the PO move the
machine higher on the backlog).
For the first sprint they will most likely not discuss done criteria for the whole product increment (it
should actually look like a city with streets and contain items built by all team!). We let them fail by not
accepting the built items. (I believe failing and learning how to fix the issue is an extremely valuable
exercise).
5

6. Outcomes of the sprint planning are:
1. expected velocity (we put a sticky on each
team’s sprint backlog with the figure)
2. and team commitment (I ask the teams if
they can commit to the selected stories, they
usually can because planning was a team
effort)
3. tasking (up to the teams if they want to do
that, usually they have no time for that)
Sprinting
They sprint for 5 minutes (I usually project a
stopwatch application on the wall or run it on my
laptop).
Playing back rock music in the class room might
add some expressiveness.
Demonstration & Retrospection
We have 5 minutes for these two activities so they
kind of flow into each other.
When the sprint timer stops I loudly ask “So, where
is my city?!” and they start to integrate their
results… it usually takes time (to be discussed and
fixed during next releases).
Eventually they manage to demonstrate the city
increment, of course with some bugs since they
usually over-commit during the first sprint. I usually
play bad here and don’t accept lots of features.
They are asked to calculate their observed velocity.
And of course they will try to convince me that a
half-done thing gives them half points for the
velocity. I don’t accept this unless the item really
kind of works but has some missing unimportant
details (lorry has a body, wheels and a cabin, but
doesn’t have lights and other small stuff). This opens up nice discussions on calculating actual velocity.
6

7. One team was trying to prove to me their half-done building was almost ready (2 story points out
of 3) and during the discussions it just fell apart. What a nice illustration! So during the next
sprint they rebuilt it from scratch and earned their full 3 points (if I had agreed to give them 2
points out of 3, they would not have had the time to rebuild it from scratch and the quality would
have suffered).
The teams stick their observed velocity on the sprint backlogs. We also draw a velocity bar chart for each
team.
Unfinished items return from sprint backlogs onto the product backlog, we calculate total remaining
points in the backlog and update our release burn-down chart. Here I start predicting their release
completion (“Seems, in 3 sprints, you guys can release the whole city, we’ll know better soon after you
finish your next sprint”). We discuss the value of being predictive rather than trying to do too much.
And the cycle continues…
Additional discussions
Refactoring
During one LEGO session a team built quite big buildings during the first sprint so they started to realize
they would not have enough bricks to finish other items. They had to refactor (simplify!) the built
buildings to be able to build more stuff. I didn’t want to have any refactoring card in the product backlog,
so refactoring affected their velocity. If I had put the refactoring card in the backlog and let them
estimate it, their velocity would have remained the same (!) though they would have built less stuff. You
build less -> your velocity goes down. This was a nice insight for everyone
Inter-team dependencies
During another session a team could not accomplish their tower crane because some of its parts were on
the other team’s table (oops, technical dependencies). The other team refused to spend some time on the
tower crane, so the team failed to deliver it in the sprint. Later we debriefed this in detail and it appeared
that the other team refused because they didn’t want their velocity to fall because of unplanned stuff
coming from another team.
Now what would have happened if we would have had individual velocities per each team member?
The final words (for now)
I’d highly recommend people teaching Scrum to go to the nearest LEGO shop and get some of the boxes.
And yes, it is quite expensive stuff. But the sooner you get it the more ROI you and your trainees get in
time. Good luck!
And please send me feedback (alexey@scrumguides.com) - any comments, criticism, ideas, and
debriefing details from the sessions are appreciated and welcomed. We all are learning here, right?
7

8. Links:
LEGO information radiators
http://www.infoq.com/news/2008/09/lego-information-radiators
LEGO games by paircoaching
http://www.paircoaching.net/games_en.php
Discussion of LEGO as a Scrum simulation at scrumdevelopment group
http://groups.yahoo.com/group/scrumdevelopment/message/36367
SCRUMguides’ web album with the photos from the LEGO workshops
http://picasaweb.google.com/scrumguides/ScrumSimulationWithLEGO#
Have fun!
8