Scrum Card Game

Scrum Card Game is a Scrum simulation card game created by Timofey Yevgrashyn. Participants work in teams on a backlog of user story cards, each carrying a value and a workload to be completed in analysis, development, and testing. In each sprint, the team plans, simulates workdays with a die, faces events that block or unblock, and then measures the delivered value. The game concretely illustrates realistic commitment, collaboration on a single story, managing unforeseen events, and the impact of debt.

Walkthrough

1. 1

   Setting up the framework and teams

   5 to 10 min

   The facilitator sets up tables in clusters and divides participants into teams suitable for the group size. They announce: "You will experience several accelerated Scrum sprints, with a backlog, simulated days, events, and a value review. Your goal is not to win against others, but to learn how your decisions influence delivery." Each team receives the game materials without handling them yet. The facilitator specifies that the official cards are authoritative for values, work, problems, and solutions.

   Tip — Avoid presenting the game as a pure competition: otherwise, teams will seek to optimise their score at the expense of learning about Scrum.

2. 2

   Presenting the materials and the flow principle

   10 min

   The facilitator shows a user story card and points out its information: the business value and the amounts of work required in analysis, development, and testing. They explain: "A story only delivers value when it is completed according to the rules of the game; work started but not finished represents a risk and potentially debt." They also show the event cards: some create problems or blockages, while others provide solutions or unblockages. Participants ask their comprehension questions before the first sprint.

   Tip — Have a participant articulate what makes a card truly delivered; this avoids debates during the review about partial work.

3. 3

   Planning the first sprint

   10 to 15 min

   Each team examines its backlog of user story cards and chooses the stories it commits to addressing during the sprint. The facilitator gives the instruction: "Look at the value, but also the amount of analysis, development, and testing; commit to what you think you can finish, not what seems appealing." Players discuss their strategy: starting many cards, finishing few cards, or collaborating on a few stories. The facilitator circulates and gently challenges unrealistic commitments without deciding for the teams.

   Tip — Consistently ask: "What makes you believe this is feasible?" This question often triggers the first real discussion about capacity.

4. 4

   Simulating sprint days

   15 to 25 min

   The facilitator initiates the sprint and times the simulated days. Each day, each player rolls a die to perform work on a card, according to the rules of the Scrum Card Game and the indications of the official materials. Teams allocate the die result to the analysis, development, or testing of a story, then draw and apply the event cards specified by the game: blocking problems or unblocking solutions. The facilitator reminds: "You can collaborate on a single story; finishing has more value than spreading the effort."

   Tip — Maintain a brisk pace: clearly announce the transition to the next day, as endless discussions mask the desired time pressure effect.

5. 5

   Managing blockages, solutions, and debt during the sprint

   10 to 15 min

   During the simulation, the facilitator draws attention to the event cards that block or unblock work. They ask the affected teams: "What is the impact on your initial plan? Do you continue as planned, reorient your effort, or accept leaving some work incomplete?" Participants must collectively decide how to react to unforeseen events, without artificially erasing the consequences. The facilitator notes visible behaviours: mutual aid, isolation, starting new cards, abandoning or addressing blockages.

   Tip — Do not rescue teams too quickly when a problem arises: let them feel the cost of a blockage before inviting them to seek a collective response.

6. 6

   Sprint review: delivered value

   10 to 15 min

   At the end of the sprint, each team identifies the stories that are actually completed according to the rules of the game and sums only the value delivered by these stories. The facilitator emphasises: "The review does not reward the effort made; it makes visible what is actually usable." The cards started but not finished are set aside to show the work in progress and potential debt. Each team briefly shares its result, initial commitment, and the observed gap.

   Tip — Physically separate the completed, in-progress, and blocked cards: visualisation makes debt much more tangible than a simple comment.

7. 7

   Retrospective and next sprint

   15 to 25 min

   The facilitator leads a short retrospective before starting a new sprint. They ask: "What will we keep, stop, or try in the next sprint to deliver value more reliably?" Teams adjust their planning approach, collaboration on stories, and reaction to events. One or more additional sprints are played depending on the available time, following the same sequence: planning, simulated days, events, review, and retrospective. The goal is to observe learning, not just improvement in scores.

   Tip — Limit the interim retrospective to one or two concrete actions; too many improvement areas dilute the experimentation of the next sprint.

8. 8

   Final collective debrief

   10 to 15 min

   The facilitator gathers the teams and compares strategies rather than just scores. They ask participants to connect what they experienced to Scrum practices: sprint commitment, work in progress, collaboration, managing unforeseen events, review, and retrospective. They highlight moments when value truly increased and those when the team merely accumulated partial work. The conclusion focuses on possible transpositions to the participants' real projects.

   Tip — Refer back to a specific situation observed during the game; a lived example anchors learning much better than a theoretical reminder of Scrum.

Variants

• Play a first sprint without particular guidance, then explicitly introduce the idea of limiting work in progress and collaborating on fewer stories in the next sprint. The comparison makes learning very visible.
• Use the game in Scrum training by pausing longer after each review to connect observations to Scrum events: planning, review, and retrospective.
• For a large group, form several teams playing in parallel with the same type of backlog, then organise a final sharing of strategies. The facilitator circulates during the sprints and collects concrete examples for the debrief.
• Short variant: only play one complete sprint followed by an in-depth debrief focused on realistic commitment and managing unforeseen events. This version is suitable when the available time is close to 60 minutes.