Learning Scrum through Games

2011 Session

Last week at Agile Tour Toronto I had the privilege of working with my friend Paul Heidema to help introduce the basic concepts of Scrum in 60 minutes. This is a really interesting challenge, what’s the minimum amount you can teach people and still give them a taste of Scrum. In end we opted for about ~10 minutes of talking heads (spread throughout), ~30 minutes of simulation time and 15 minutes of debrief.

We invited our teams to create Children’s Books of the Goldilocks story. Along with the basic Story participants were asked to offer advertising, public service announcements etc.

Comments from participants:

• A number said it was surprising how well teams of complete strangers came together after two sprints.
• Several didn’t like the way I set them up for a mini “failure” by not playing the Product Owner role poorly and not communicating my needs. This is a fair point however it does simulate life with a real product owner

Feel free to use this simple simulation to help teach the very basic concepts of Scrum.

2012 Update

Last year I created a short session - Learning Scrum Through Games - to help people explore the basics of Scrum in a one hour format. This year I rewrote it and took it to both Agile Tour Toronto and Ottawa.

We learned a number of interesting things from both sessions:

• Even with a poor quality Product Backlog (the Backlog I gave attendees has many issues) the team was still able to create a pretty good product.
• I don’t give the best instructions to start the exercise and yet attendees manage to create some great comics. When a real Scrum team starts, it’s chaotic at first. I would prefer attendees get a sense of this during the exercise so I give deliberately vague instructions.

• Done or Not Done - Incomplete Comics lead to a good discussion, there is no such thing as 80% done in Scrum. Working software (or comics in this case) is the only measure of progress. This topic led to a brief conversation around the importance of shippable product after every Sprint.
• Many teams jumped around the Product Backlog: choosing whichever stories they felt they could complete. They didn’t ask the Product Owner if it was okay to implement items out of order. Some teams went even further by implementing things the Product Owner didn’t ask for. Quick reminder: if the team wants to do things in a different order or do new things, they have to ask the Product Owner first.
• In Toronto several attendees remarked that it was difficult to understand what was going to happen next. In Ottawa I created an Index Card - Scrum Task wall.
• Timings - the timings in the one handout didn’t work out as well as I’d hoped. It’s not realistic to run two sprints in one hour. If you’re trying to run this yourself I recommend one and a half to two hours which will allow enough time for two Sprints and a good debrief.

Finally, when running this the goal isn’t a perfectly run exercise or perfect comic book; its aim is to have people experience the chaos that is Scrum and see how it can work.

Handouts

Intro to Scrum with Games Backlog and Schedule (pdf) and Introduction to Scrum Concepts (pdf)

Slides

Caveat - the slides were just indeed as a backdrop and not stand on their own.

Learning Scrum through games from Mark Levison

Photos by Mark Levison