Lego Simulation Scrum Workhop

This page describes a Lego Simulation Scrum Workshop. To experience Scrum, it is important to deliver a product, work together as a team, and do several iterations. To simulate this, the attendees will build a city with Lego bricks. There will be user stories, planning sessions, sprints, review sessions, retrospectives, etc.

The goal of the workshop is to have the attendees experiencing Scrum by really using it

The polytechnic Fontys Eindhoven asked me many years ago to organize a workshop about Scrum. The goal was to have the students experience Scrum. Secondly, in my opinion, it should be fun. The first thing that came to my mind was building something with Lego bricks. The idea was not new, and after some Googling, I found the site http://www.lego4scrum.com/. The website describes a workshop to experience Scrum by using Lego brick. Alexey Krivitsky created the site.

I used the concept of Alexey Krivitsky as the basis for my workshop. I made one significant change; I added a retrospective to the simulation. I believe a retrospective is one of the essential parts of Scrum.

On this page, you will read what you need to prepare to organize this workshop yourself. You can of course also ask me to facilitate the workshop.

Time, Groups, Lego

The total time of the workshop will be around 120 minutes. Best is to plan three hours, to be on the safe side. Depending on the audience, you will need more time to explain some basic concept of Scrum.

The attendees have to work in groups. Groups of minimum three people and maximum nine people, as described in the Scrum guide. It is not necessary to define the groups before the workshop; this is part of the workshop.

The city will be built with Lego. Therefore, you will need a lot of Lego bricks. You could, for example, use bricks like this. You will also need flipcharts, one flipchart per group, and three flipcharts extra. You need the extra flipcharts to create a release burndown, sprint overview, and the agenda. Depending on your workshop, you also need planning poker cards.

The room should be large enough to work comfortably for three hours (maximum) with a group of approximately 40 people. With 40 people the group will split up into five to eight groups. Every team will need a table to work together. Additionally, there is one extra table required to show the result.

The following roles will be present during the game/workshop:

    • Product Owner, the facilitator will act as Product Owner;
    • Developers, every attendee will fulfill the role of a developer in a team.

There will be no Scrum Master or other specialized team roles like testers.

Introduction

Depending on the audience, you start by explaining Scrum. The roles, artifacts, events, and process.

Scrum is about self-organizing teams. The first assignment will be to organize the teams. It is up to the attendees to self-organize. The teams should be 3-9 people, that is the only constraint. Ask the teams also to come up with a team name.

When the teams are created, explain the roles. The facilitator will be the Product Owner, no Scrum Master this time and the teams are there to build the city. Oh, indeed also explain them you want the development teams to create a city. Challenge them to be creative, and you would like to have one city. The main building elements are Lego bricks. Cheating is not possible…

Product Backlog

Next step is to explain user stories, estimations, and planning poker. These are not part of Scrum, but are common practices.

The requirements of the city are described by using user stories. Explain the concept of user stories, especially the conversation part. It is not necessary to discuss all user stories, just some examples.

When you explained user stories, also show some examples. The next step is to explain estimation and the planning poker game. The teams need to estimate all user stories. When you told about estimations and planning it is time for the team to start estimating all user stories. Just put all the user stories on the wall and have the teams estimate them one by one. The product owner can if necessary answer questions. When this is done, all or at least most of the user stories should be estimated. Make sure you have one small user story as an example, to make sure the teams have a reference point.

To finish this part, summarize the points on all user stories to have a total number of points for the release backlog. Update the release burndown flipchart with the total number of points.

Sprints

The backlog is ready, the teams are ready, time to start the first sprint.

Ask the teams to do a sprint planning. How much user stories do they think they can realize in the first sprint? This should take maximum three minutes. When the teams are done, update the sprint overview board. What is the forecast for every team?

Let’s start the first sprint… seven minutes timeboxed! Make sure you are available as Product Owner for questions, where the first sprint you will not get many questions, trust me.

After precisely seven minutes end the sprint, everyone raises your hands! Time for the sprint review.

As you work with multiple teams, you would like to see one integrated city on the table in the front. My experience so far, you will end up with only local cities, one on every table… As Product Owner you decide if the user stories are done, do you like constructions with all kind of colors, or do you prefer buildings in one color? Make sure the teams experience the most common mistakes. In my workshops, there are not many teams who deliver their forecast in the first sprint. Also, update the release burndown and the team sprint overview dashboard.

Time for a retrospective. After every sprint, the team should have a short retrospective. Key is to improve as a team. There are many activities you can use in a retrospective. Prepare the retrospective flipcharts upfront; the questions could be:

  • Stop, what should we stop doing?
  • Start, what should we start doing?
  • Continue, what should we continue doing?
  • Whom would you like to compliment?

Explain the concept of actionable items. Otherwise, the retrospective is a waste of time. The retrospective is also timeboxed and will take five minutes.

One sprint cycle is:

  • Planning, 3 minutes
  • Sprint, 7 minutes
  • Review, 5 minutes
  • Retrospective, 5 minutes

Debriefing

After the last sprint, do a debriefing session. Questions that you could ask the group:

  • What did you observe?
  • How did it feel being on a Scrum Team?
  • Did you change your strategy during the release?
  • How was the link between the theory and applying scrum?
  • What problems did you encounter and could you not solve?
  • What did you learn?

Make sure you have a happiness door, to collect feedback from the attendees when they leave the workshop.

If you are interested in this workshop, feel free to reach out to me. Just contact me.