SCRUMCARDGAME 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 makes participants prepared for the real use of Scrum.
This game is usually played during the training or workshop. Participants should know about the Scrum framework or could be introduced to it right before the game.
Please visit official web-site to read detailed game manual for Scrum Card Game
You would need around 45-60 minutes for the whole gameplay.
If you do it as a separate session, consider 2+ hours for including an intro of Scrum and an extended debriefing of all cases during the game and their real-life analogues.
Split the audience into teams of 4-5 (max 6) people, equally if possible and have one set per team.
For each team you need:
- Buy a printed set and reuse it for each play.
- Download a detailed manual with self-printable cards included
- Play Online by starting a game and inviting participants with a link.
Hint: Each team has an equal set, but due to decisions they make, the game can go differently in each case. This creates an infinite source for discussions during the debriefing.
Also, a Flipchart and markers for the facilitator needed to visualize results.
Set the Goal: You are development team(s) aimed to deliver a new in-house enterprise level communication application.
Each team has an equal set, but due to decisions they make the game can go differently in each case. This creates an infinite source for discussions during the debriefing.
- Provide each team with a set of Story cards
- Cards with stories forming the “Backlog” deck
- The backlog is prioritized (sequence number in the top left corner) and estimated (hours in the bottom corner)
- The team has 3 days per iteration (there will be a maximum of 3 iterations)
- Every iteration consists of:
- Planning and commitment
- Work within iteration
- Sprint Review + Retrospective
- Make the group arrange a simple Task Board by marking TODO, IN PROGRESS, DONE columns with simple sticky notes to visualize their state.
- Prepare a flipchart list with visualization of PLAN and ACTUAL columns for each team in play.
- Ask teams “how many features you believe you could deliver per iteration?”
- In the first round let every team calculate their number of man-hours per iteration as they usually like to do. Allow them to make even over-optimistic commitment 🙂
- To perform 2nd and 3rd planning you ask teams to use the historical data.
- Put selected cards from “Backlog” into the TODO column.
- Write down commitment as the total number of estimates and IDs/numbers of Stories of every team on a flip chart into the “Plan” column.
Work each Day within iteration
A day is when each player did their move in a circle. After everyone in a team participated, the next day starts automatically.
Every team member in their turn should:
- Select a Story to work on (it should appear in “IN PROGRESS”)
- Roll two dice to determine the number of productive hours per day
- Give two dice right after explaining this step
- Deduct number on the dice from remaining hours on the card (s)he “works on”
- Advise players to calculate remaining as it helps to avoid mistakes
- To simplify tracking participants can stick a post-it on a card and write
remaining time there
- Pull the card from the “Chance” deck
- Give a “Chance” deck right after explaining this step
- Do whatever the card says.
There are three possible types of cards:
- Event – a one-time action, that affects immediately and discarded after the play
- Problem – these sticky issues are blocking the Story that the player was “working on”. Each problem is a case taken from real-life, a team could bring examples or details into each Problem from their experience.
- Blocking means the team can’t move it into a DONE state, they have to find a Solution for the kind of problems stated on a card.
- Blocking doesn’t prevent from continuing work on a Story (deducting hours until zero).
- Sometimes, positive Events could also help with Problems 🙂
- Solutions – is a team’s asset or action which can be applied at any time to solve a problem and unblock a Story. Once Solution applied the Problem and Solution cards are discarded.
- Solutions could be collected by the team if there are no appropriate Problems – they are collected from iteration to iteration and belong to the whole team.
- If User Story is done (0 hours remaining and no blockers) – move it to the DONE column.
- DONE criteria for a Story:
- Team members delivered the number of hours equal to or greater than the estimate for a Story
- A Story is not blocked with a Problem.
Once again, at every “day” each player does follow:
- Choose a card to “work on”
- Throw two dices
- Pick a Chance card and do what it says
Sprint Review + Retrospective
- After each player has passed 3 turns – the Sprint is over.
- Each team should present Stories accomplished (i.e. only stories in DONE column) and calculate the actual result as the total of DONE Stories.
- Compare Actual result with initial Plan.
- Review undone work and discuss the reason, also discuss how to account these un-done Stories in next Sprint to make sure we maintain the total number from the original estimations.
- Retrospect on how to perform in next Sprint to achieve more.
Learning points (debriefing with the teams):
To start debriefing you should bring in front of the audience the flipchart(s) with visualizing all Planned and Actual data for each of three sprints.
Here are some topics to start with:
- Planned vs Actual
- Velocity variations
- Hours Estimate vs Size (Original Estimate)
- Major risks happened (Technical, People, Unplanned Events)
- What are the hardest types of risks to take?
- Could we forecast bad events?
- and etc…
Give it a try!
Order a printed set or download self-printable cards. This material is licensed to each customer individually for your personal use in any commercial and internal purposes, without rights to reproduce and resell.
Or Play Online with your teams or clients.
© Timofey (Tim) Yevgrashyn, 2010.
See our Terms and Conditions for additional details.