Scrum Card Game rules and manual

Home » Scrum Card Game rules and manual

Scrum Card Game is a simple simulation that lets players experience work in Scrum sprints and discusses many questions and topics that happen in real life while working in a Scrum team. This experience facilitates learning and prepares participants for the actual use of Scrum. This game manual will prepare you to facilitate your group’s learning experience.

This game is usually played during the Scrum training or a workshop. Participants should know about the Scrum framework or could be introduced to it right before the game. At least you should explain the concept of Iteration (Sprint) and the Plan-Do-Reflect cycle.

Despite other simulations, this one strongly focuses on Scrum as a process and provides education on mechanics through serious play. Also, it is lightweight and easy to carry on a set of cards that you can bring in your pocket to any workshop or training.

In short, a team experience three Scrum Sprints with a normal iteration cycle Plan-Do-Reflect. Each Sprint is three-day-long to simplify learning.

The setup of the game

Split the audience into teams of 3-4-5 (max 6) people, equally if possible, and have one set per team.

For each team, you need the following:

  1. Buy a printed set and reuse it for each play.
  2. Download a detailed manual with self-printable cards included 
  3. Play Online by starting a game and inviting participants with a link.

Hint: Each team has an equal set, but the game can go differently in each case due to their decisions. This creates an infinite source for discussions during the debriefing.

Prepare a “Backlog” of Story cards and a “Chance set” from well-shuffled Event, Problem, and Solution cards. The Backlog is prioritised (sequence number in the top corner) and estimated (hours in the bottom).

In the offline setup, you could arrange a task board (with Todo, In Progress, and Done columns) and prepare a flip chart with PLAN and ACTUAL visualisation.

Set the Goal: You are a competitive development centre (s) aimed to deliver a new application to the market.

Team Planning

  • Ask the team, “how many features do you believe you can deliver in the next iteration?”.
  • The team plans a three-day iteration by selecting Stories from a Backlog into the Todo column.
  • The Planning process is done when a team announces its plans.
  • In an offline setup, you could record the flipchart numbers of Stories selected and the total amount of planned work so that everyone can see their «commitment».

Work within an iteration

Each player should:

  • Explicitly select a Story to “work on.
  • Roll dice – this is the player’s number of productive hours on this day
  • Deduct from remaining hours on the card(s) this player “works on” (it’s done automatically in the online version)
  • Pull a card from the “Chance set” (shuffled Events, Problems, Solutions together)
  • Do what the card says:
    • Problem – sticks and blocks a Story the player is “working on”
      • Blocking means you can’t move into DONE and have to find a Solution first
      • You can continue to work on(deducting to 0)
    • Solution you may apply at any time. Solves a Problem and unblocks a Story. Once used, the Problem and Solution discarded
    • Event – immediate effect and then discarded
  • Solutions belong to the whole team
  • Solutions preserved from iteration to iteration

DONE criteria for a Story:

  • A Story has 0 hours remaining
  • A Story has no unsolved Problem cards attached

Sprint Review + Retrospective

  • After each player has done three rounds – the iteration is over
  • The team should present Stories accomplished (i.e., only stories in the DONE column) and calculate the total of original estimations of done Stories
  • Compare Actual results with the initial Plan
  • Review work not done and discuss the reasons. Also, discuss how to account for these un-done Stories in the next Sprint to respect the original estimations’ number.
  • Retrospect on how to perform in the next Sprint to achieve better results

Hint: Teams are not expected to accomplish the whole Backlog, but sometimes they can do so. I usually say that the last Sprint is the one before going to production, and a team should better plan what they can deliver by the end of Sprint and the rest of the Stories ignored.

Debriefing after the game

In the offline setup, bring the flipchart to visualise all Planned and Actual data.

Hint: Do the game debriefing to match your teaching goals.

Here are some topics for inspiration:

  • Planned VS Actual
  • Velocity variations
  • Hours Estimate VS Size (Original Estimate)
  • What type of risks affected the play (Technical, People, Unplanned Events)
  • Could we forecast unfortunate events?

Give it a Try!

I’d love to hear any feedback about how you use the game or ideas on how to extend or alter the game. Please don’t hesitate to contact me.

Order a printed set or download self-printable cards. This material is licensed to each customer individually for your personal use in commercial and internal purposes, without the right to reproduce and resell.
Or Play Online with your teams or clients. 

© Timofey (Tim) Yevgrashyn, 2010. 
See our Terms and Conditions for additional details.