Overview

An Agile product development simulation game with LEGO®, Scrum, story maps, experiments, etc. This game tries to cover an entire product development process, the Agile way, and is designed for a single team of 4 to 6 people.

Rationale

Many games exist for teaching Agile basics. Unfortunately none of the games I could find was both complete enough to describe the entire product development process, including building a backlog and making MVP experiments, and compatible with a small team of 5 people. That is why I decided to create this game. If you are only interested in the pure-Scrum part then you might want to give a try to lego4scrum, which is one of the most popular games nowadays and was a great source of inspiration to me.

What the game covers

• Agile product development
  • Story maps
  • Product experiments / MVP
  • User feedback and adaptation
• Scrum
  • Sprint Planning
  • Auto-organizing team
  • Sprints
  • Daily Scrum
  • Sprint Review / Demo
  • Retrospective

What you need

• A team of 4 to 6 people
• A whiteboard
• Whiteboard markers
• Sticky notes, at least 2 different colors
• Pens
• A stopwatch
• Lego. I use one 10696 box
• At least 2 hours

Before the game

This game was initially designed to explain the principles behind Agile product development to a team of digital marketing students, who had no idea of what Agile or Scrum is. In such a situation you might have to begin with a short presentation of the key concepts, particularly for the Scrum part. Nevertheless, the game itself is designed to allow explanations at each step so you may prefer not going too deep into the details before beginning to play.

The Game

Presentation

This game is a simulation of a virtual company named MyToy (or whatever you want to call it). MyToy is a company that develops customized toys with Lego pieces. Children are MyToy’s end-users, and their parents our customers. MyToy receives orders directly from children who describe the way they would want to play with their toy. It is MyToy’s job to create a toy that will satisfy the most their end-users, and their parents.

MyToy uses Scrum as a framework to building the toys. Each toy development is given a “budget” of 3 sprints of 4 minutes each.

Step 0 : Introduction

As a facilitator you must first set the stage. People must feel like this is a real company. You want them to get really involved in the product development process if you want the game to succeed.

You must present MyToy and explain the process. You want to insist on the fixed-budget aspect here because we need the team to feel a bit stressed since the very beginning.

As a facilitator you will play the product owner role. You might want to name a scrum master but I would not recommend it. If you play the game with an existing Scrum team though, you can keep existing roles during the game.

Step 1 : The Order

After setting the context, you begin to talk about the order your team will have to handle. Some people like working with personas so feel free to describe the child and his/her parents in a very real way.

Then read the order aloud. I recommend you show it somewhere too. The order should be both broad and precise. I like a big story like “I take my Wiiizvroom, put a lego inside who starts to drive it on the road. Vroom! And then it meets another Wiiizvroom and begins to talk with him, because actually it’s a boy. But quick! The Wiiizvroom is late and must deliver his cargo. He takes off to get to his appointment faster”

Step 2 : Story Map

Big Picture

Collectively, list all the key things the child can do with his toy, and write each of them on a sticky note. If you followed the example order described above, you might come up with things like “put a lego character inside”, “drive it”, “fly it”, “load it with some cargo”, etc.

Add to this list any user task your audience can think of. The first time I played this game we added “make engine noise”.

Ideally you should add stories for other people, like the parents or maybe some virtual marketing people in the company. The key thing here is try to make it real.

Place all your sticky notes on the whiteboard. Align them horizontally and try to order them from the most (left) to the least important (right).

Options

For each note try to collectively list implementation options. If you have a “fly it” note, options might for example be “wings”, “helix”, “rotor blades”, “jet engine”, etc.

Write each option on a  separate sticky note. And stick them in a column under the corresponding “big picture” note. You should use notes of a different color than when describing the “big picture”.

When you are done you should sort each column. I like to first sort notes by increasing apparent complexity (from up to bottom). Later in the game this order is likely to change.

Step 3 : Sprint Planning

The first Sprint is a good moment to try to get feedback on the various options and assumptions your team made while building the story map.

As a facilitator, invite the team to select as many “stories” from the bottom part of the map as they believe they can build in 4 minutes. Try to make it clear that we want to test assumptions and reduce risks. Be very user-centric.

As you talk about each top story, collectively determine acceptance criteria out and write them on each post-it.

You might want to run an estimation session here, but personally I prefer to trust the team and let them choose as many stories as they want.

My advice here is to draw a line on the whiteboard under the selected items to visualize the contents of the Sprint.

Step 4 : Sprint

Once the stories are selected the first Sprint can start.

Let the team create a “development” environment during 1 or 2 minutes. They should not start building anything though, so you should keep the Lego pieces with you.

You have the choice between running the full 4 minutes or splitting them into two 2-minute sessions with a 1-minute “Daily” Scrum halfway. If you opt for the 2×2+1 option you might want to draw a scrum board somewhere and copy the selected stories on new notes that you will stick on a “backlog” column. Having a stand-up meeting is interesting of course, but you might learn many things during the debriefing discussion, at the end of the game, from the lack of a synchronization meeting, which will help you prove how useful a stand-up meeting is. It’s up to you.

During the Sprint you should act as a Product Owner, answer questions and make decisions and put a little bit of pressure on the team when needed. Try to watch the building process closely.

Step 5 : Sprint Review

Move the first product to a demo environment. Not a big thing here, just another table to make sure people don’t think too much about the Lego pieces on the “development” environment.

The team makes a demonstration of the stories they developed. Chances are that the product at this stage is anything but viable, but you must show it to the end-user anyway, and gather his feedback.

As a facilitator you must make sure that we learn something here, so be imaginative. If any assumption was made – and I hope so – you have to validate some of them and above all invalidate others. If you followed my example, your team might have chosen to try and make a plane, with wings and helices : say that the kid realized he wanted an helicopter !

Also list any bug you noticed and write them on notes of a different color.

Every new pieces of information must go update the story map, under the relevant column.

Step 6 : Retrospective

Allow the team to run a 1 or 2-minute retrospective.

Next Two Sprints

Repeat everything from step 3 twice again. If after Sprint #3 the product is still not satisfying, allow one last Sprint but make sure everybody understands that we are losing money. Our company cannot afford to release such a low quality product, etc.

Debriefing

Take a break. Everybody needs a break at this moment.

Conclude the game by having a debriefing discussion. Ask the team about what they observed, how they felt during the game and what they would do differently if they could play the simulation again. Ask how they perceived your role as a product owner. As the facilitator it is your moment 🙂

Thank You

Thank you very much for reading these game instructions. I hope the game will be useful to you and help your students understand more about how Agile product development works.

Please let me know if you played the game or have any comment or suggestion by leaving a reply at the bottom of the page, or by using the contact form below.