SCRUM CARD GAME is the simple game, which lets players experience work in Scrum sprints and brings to discussion many questions and topics that happen in real life while working in a Scrum team. This experience facilitates learning and makes participants prepared to the real use of Scrum.

This game is usually played during the training or workshop. Participants should know about Scrum framework or could be introduced to it right before the game.

I built this game as I felt other simulations (for example, Lego Scrum or other kinds) lack the focus on the Scrum process and often derail participants with too much into the play instead of learning. Also, I like the lightweight and easy way to carry on materials and this game is just a set of cards that you can bring in your pocket to any workshop or training you have.

Timing

You need around 60 minutes for the whole game.
If you do it as a separate session, consider 2+ hours for including intro of Scrum and an extended debriefing of all cases during the game and their real-life analogs.

The Setup

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:

  1. Download a detailed manual with printable cards included (the best is to print and laminate them for re-use or buy a printed one).
    Each set contains: Stories and Chance (Events, Problems, Solutions) cards
  2. Get two regular playing dice (1..6) for each team
  3. Stickers and a pen for each team to organize a taskboard and write remaining work on stickers and not on cards directly.

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.

Preparation

  • Provide each team with a set of Story cards
    • Cards with stories forming the “Backlog” deck
    • Backlog is prioritized (sequence number in top left corner) and estimated (hours in bottom corner)
  • Team has 3 days per iteration (there will be maximum 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.

 

Planning

  • 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 TODO column.
  • Write down commitment as the total number of estimates and IDs/numbers of Stories of every team on a flip chart into “Plan” column.

 

Work each Day within iteration

A day is when the 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 this day
    • Give two dice on a first round 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 on a first round 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 the real life, a team could bring examples or details into each Problem from their experience.
      • Blocking means the team can’t move it into DONE state, they have to find a Solution for the kind of problems stated on a card.
      • Blocking doesn’t prevent from continue 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 or greater than 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!

Download a copy of the detailed manual with printable cards included.

I’ve released this game under a Creative Commons Attribution-ShareAlike 4.0 International License. You are free to use it at a workshop in your company or in your course you are teaching, even if you are charging money for it. I’d love to hear from you any feedback about how you use the game or ideas how to extend or alter the game. Please don’t hesitate to contact me.
Creative Commons License

Translations

At the moment, the game is available in English, Russian, Spanish, German, Italian, Portuguese, Dutch

Please don’t hesitate to contact me if you want to translate the Scrum Card Game to another language.

SCRUM CARD GAME is the simple game, which lets players experience work in Scrum sprints and brings to discussion many questions and topics that happen in real life while working in a Scrum team. This experience facilitates learning and makes participants prepared to the real use of Scrum.

This game is usually played during the training or workshop. Participants should know about Scrum framework or could be introduced to it right before the game.

I built this game as I felt other simulations (for example, Lego Scrum or other kinds) lack the focus on the Scrum process and often derail participants with too much into the play instead of learning. Also, I like the lightweight and easy way to carry on materials and this game is just a set of cards that you can bring in your pocket to any workshop or training you have.

Timing

You need around 60 minutes for the whole game.
If you do it as a separate session, consider 2 hours for including intro of Scrum and an extended debriefing.

The Setup

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:

  1. Download a detailed manual with printable cards included (the best is to laminate them for re-use).
    Each set contains: Stories and Chance (Events, Problems, Solutions) cards
  2. Get two regular playing dice (1..6) for each team
  3. Stickers and a pen for each team to organize a taskboard and write remaining work on stickers and not on cards directly.

Also, a Flipchart and markers for the facilitator needed to visualize results.

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

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.

Preparation

  • Provide each team with a set of Story cards
    • Cards with stories forming the “Backlog” deck
    • Backlog is prioritized (sequence number in top left corner) and estimated (hours in bottom corner)
  • Team has 3 days per iteration (there will be maximum 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.

 

Planning

  • 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 would like to do.Allow them to make even optimistic commitment 🙂
    • To perform 2nd and 3rd planning you ask teams to use historical data.
  • Put selected cards from “Backlog” into TODO column.
  • Write down commitment as the total number of estimates and IDs/numbers of Stories of every team on a flip chart into “Plan” column.

 

Work each Day within iteration

A day is when the 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 this day
    • Give two dice on a first round 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 on a first round 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 the real life, a team could bring examples or details into each Problem from their experience.
      • Blocking means the team can’t move it into DONE state, they have to find a Solution for the kind of problems stated on a card.
      • Blocking doesn’t prevent from continue 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 DONE column.
  • DONE criteria for a Story:
    • Team members delivered the number of hours equal or greater than 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!

Download a copy of the detailed manual with printable cards included.

I’ve released this game under a Creative Commons Attribution-ShareAlike 4.0 International License. You are free to use it at a workshop in your company or in your course you are teaching, even if you are charging money for it. I’d love to hear from you any feedback about how you use the game or ideas how to extend or alter the game. Please don’t hesitate to contact me.
Creative Commons License

Translations

At the moment, the game is available in English and I have a Russian translation to be published soon.

A friend of mine works to make a German translation. Please don’t hesitate to contact me if you want to translate the Scrum Card Game to another language.

SCRUM CARD GAME is the simple game, which lets players experience work in Scrum sprints and brings to discussion many questions and topics that happen in real life while working in a Scrum team. This experience facilitates learning and makes participants prepared to the real use of Scrum.

This game is usually played during the training or workshop. Participants should know about Scrum framework, or could be introduced to it right before the game.

I built this game as I felt other simulations (for example, Lego Scrum or other kinds) lack the focus on the Scrum process and often derail participants with too much into the play instead of learning. Also, I like the lightweight and easy way to carry on materials and this game is just a set of cards that you can bring in your pocket to any workshop or training you have.

Timing

You need around 60 minutes for the whole game.
If you do it as a separate session, consider 2 hours for including intro of Scrum and an extended debriefing.

The Setup

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:

  1. Download a detailed manual with printable cards included (the best is to laminate them for re-use).
    Each set contains: Stories and Chance (Events, Problems, Solutions) cards
  2. Get two regular playing dice (1..6) for each team
  3. Stickers and a pen for each team to organize a taskboard and write remaining work on stickers and not on cards directly.

Also, a Flipchart and markers for the facilitator needed to visualize results.

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

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.

Preparation

  • Provide each team with a set of Story cards
    • Cards with stories forming the “Backlog” deck
    • Backlog is prioritized (sequence number in top left corner) and estimated (hours in bottom corner)
  • Team has 3 days per iteration (there will be maximum 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.

 

Planning

  • 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 would like to do.Allow them to make even optimistic commitment 🙂
    • To perform 2nd and 3rd planning you ask teams to use historical data.
  • Put selected cards from “Backlog” into TODO column.
  • Write down commitment as the total number of estimates and IDs/numbers of Stories of every team on a flip chart into “Plan” column.

 

Work each Day within iteration

A day is when the 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 this day
    • Give two dice on a first round 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 on a first round 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 the real life, a team could bring examples or details into each Problem from their experience.
      • Blocking means the team can’t move it into DONE state, they have to find a Solution for the kind of problems stated on a card.
      • Blocking doesn’t prevent from continue 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 DONE column.
  • DONE criteria for a Story:
    • Team members delivered the number of hours equal or greater than 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!

Download a copy of the detailed manual with printable cards included.

I’ve released this game under a Creative Commons Attribution-ShareAlike 4.0 International License. You are free to use it at a workshop in your company or in your course you are teaching, even if you are charging money for it. I’d love to hear from you any feedback about how you use the game or ideas how to extend or alter the game. Please don’t hesitate to contact me.
Creative Commons License

Translations

At the moment, the game is available in English, Russian, Spanish, German, Italian, Portuguese, Dutch

A friend of mine works to make a German translation. Please don’t hesitate to contact me if you want to translate the Scrum Card Game to another language.

SCRUM CARD GAME is the simple game, which lets players experience work in Scrum sprints and brings to discussion many questions and topics that happen in real life while working in a Scrum team. This experience facilitates learning and makes participants prepared to the real use of Scrum.

This game is usually played during the training or workshop. Participants should know about Scrum framework, or could be introduced to it right before the game.

I built this game as I felt other simulations (for example, Lego Scrum or other kinds) lack the focus on the Scrum process and often derail participants with too much into the play instead of learning. Also, I like the lightweight and easy way to carry on materials and this game is just a set of cards that you can bring in your pocket to any workshop or training you have.

Timing

You need around 60 minutes for the whole game.
If you do it as a separate session, consider 2 hours for including intro of Scrum and an extended debriefing.

The Setup

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:

  1. Download a detailed manual with printable cards included (the best is to laminate them for re-use).
    Each set contains: Stories and Chance (Events, Problems, Solutions) cards
  2. Get two regular playing dice (1..6) for each team
  3. Stickers and a pen for each team to organize a taskboard and write remaining work on stickers and not on cards directly.

Also, a Flipchart and markers for the facilitator needed to visualize results.

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

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.

Preparation

  • Provide each team with a set of Story cards
    • Cards with stories forming the “Backlog” deck
    • Backlog is prioritized (sequence number in top left corner) and estimated (hours in bottom corner)
  • Team has 3 days per iteration (there will be maximum 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.

 

Planning

  • 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 would like to do.Allow them to make even optimistic commitment 🙂
    • To perform 2nd and 3rd planning you ask teams to use historical data.
  • Put selected cards from “Backlog” into TODO column.
  • Write down commitment as the total number of estimates and IDs/numbers of Stories of every team on a flip chart into “Plan” column.

 

Work each Day within iteration

A day is when the 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 this day
    • Give two dice on a first round 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 on a first round 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 the real life, a team could bring examples or details into each Problem from their experience.
      • Blocking means the team can’t move it into DONE state, they have to find a Solution for the kind of problems stated on a card.
      • Blocking doesn’t prevent from continue 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 DONE column.
  • DONE criteria for a Story:
    • Team members delivered the number of hours equal or greater than 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!

Download a copy of the detailed manual with printable cards included.

I’ve released this game under a Creative Commons Attribution-ShareAlike 4.0 International License. You are free to use it at a workshop in your company or in your course you are teaching, even if you are charging money for it. I’d love to hear from you any feedback about how you use the game or ideas how to extend or alter the game. Please don’t hesitate to contact me.
Creative Commons License

Translations

At the moment, the game is available in English and I have a Russian translation to be published soon.

A friend of mine works to make a German translation. Please don’t hesitate to contact me if you want to translate the Scrum Card Game to another language.

SCRUM CARD GAME is the simple game, which lets players experience work in Scrum sprints and brings to discussion many questions and topics that happen in real life while working in a Scrum team. This experience facilitates learning and makes participants prepared to the real use of Scrum.

This game is usually played during the training or workshop. Participants should know about Scrum framework, or could be introduced to it right before the game.

I built this game as I felt other simulations (for example, Lego Scrum or other kinds) lack the focus on the Scrum process and often derail participants with too much into the play instead of learning. Also, I like the lightweight and easy way to carry on materials and this game is just a set of cards that you can bring in your pocket to any workshop or training you have.

Timing

You need around 60 minutes for the whole game.
If you do it as a separate session, consider 2 hours for including intro of Scrum and an extended debriefing.

The Setup

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:

  1. Download a detailed manual with printable cards included (the best is to laminate them for re-use).
    Each set contains: Stories and Chance (Events, Problems, Solutions) cards
  2. Get two regular playing dice (1..6) for each team
  3. Stickers and a pen for each team to organize a taskboard and write remaining work on stickers and not on cards directly.

Also, a Flipchart and markers for the facilitator needed to visualize results.

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

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.

Preparation

  • Provide each team with a set of Story cards
    • Cards with stories forming the “Backlog” deck
    • Backlog is prioritized (sequence number in top left corner) and estimated (hours in bottom corner)
  • Team has 3 days per iteration (there will be maximum 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.

 

Planning

  • 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 would like to do.Allow them to make even optimistic commitment 🙂
    • To perform 2nd and 3rd planning you ask teams to use historical data.
  • Put selected cards from “Backlog” into TODO column.
  • Write down commitment as the total number of estimates and IDs/numbers of Stories of every team on a flip chart into “Plan” column.

 

Work each Day within iteration

A day is when the 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 this day
    • Give two dice on a first round 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 on a first round 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 the real life, a team could bring examples or details into each Problem from their experience.
      • Blocking means the team can’t move it into DONE state, they have to find a Solution for the kind of problems stated on a card.
      • Blocking doesn’t prevent from continue 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 DONE column.
  • DONE criteria for a Story:
    • Team members delivered the number of hours equal or greater than 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!

Download a copy of the detailed manual with printable cards included.

I’ve released this game under a Creative Commons Attribution-ShareAlike 4.0 International License. You are free to use it at a workshop in your company or in your course you are teaching, even if you are charging money for it. I’d love to hear from you any feedback about how you use the game or ideas how to extend or alter the game. Please don’t hesitate to contact me.
Creative Commons License

Translations

At the moment, the game is available in English and I have a Russian translation to be published soon.

A friend of mine works to make a German translation. Please don’t hesitate to contact me if you want to translate the Scrum Card Game to another language.

13 thoughts on “Scrum Card Game”

    1. Hi,
      Thanks for contacting me.
      The ScrumCardGame website had some technical issues a few days ago. Now it works as usual.
      Please try again to download the game! 🙂

      P.S.
      According to European regulation, you should opt-in first to receive further communication from the website. Please make sure you found the activation email in your mailbox.

      With best regards,
      Timofey Yevgrashyn
      Author of ScrumCardGame – simple Scrum simulation
      http://scrumcardgame.com

  1. Hi Ady,

    As mentioned, in the detailed manual you could have some additional guidance (it is also included in the printed set).

    The whole play could take from 45 minutes to several hours. Depends on how much you would combine the play with education and coaching and debriefing each case on the spot or afterward all together.

    There are 3 iterations recommended in the game. Each iteration repeats the pattern Plan-Act-Reflect. But, obviously, when people do the first sprint ever, they need more time for each part. When the second and third iteration played – they take less time and could go faster.

    Regards,
    Tim

  2. This is fabulous. I’m thinking of buying couple of units. Would be grateful if you would advise how much time should be spent on the key areas please

  3. Hi Tim,
    we played the Scrum Card Game at an Agile User Group event.
    I really loved it and the general feedback was positive.
    One feedback in particular pointed out that the different meetings were not scaled-down time boxes of the Scrum framework (as in other Scrum simulations) and thus made it possible to improve and learn.
    Here’s a link to a summary of the evening: http://agileaugsburg.de/2016/10/scrum-card-game/ (in German 🙂
    I totally recommend this game.
    Thanks for providing it –
    Cheers, Anja

  4. Hi Tim,
    We’ve played the game today. It’s very interesting game, but we had a lot of question. I’ll be grateful to you for helping. If some tasks were done during of first iteration what have that person to do who finished her/his tasks? If my team (5 people) chose 7 tasks, what are we doing from another tasks or how much tasks we should choose before starting game? Can we take more tasks before second iteration?
    Best regards,
    Vita!

    1. Hi Vita,

      As I said, this game brings to discussion many cases from the real life.
      Pulling more work into the sprint is one of the common cases. What a team should do if they are done with commitments and still have a spare time? Good question – you could discuss with your team what would they do in real life.

      Usually, my personal belief, that a good team could pull next from the backlog. The good point as it is not promised to deliver there should be no objections if you start and not finish it – you just used a spare time 🙂 Of course, for the next sprint this story requires fewer efforts to get it done and will boost the team’s results.

      Another good question is what to do with the leftovers and how many tasks should a team take on top of inherited from the previous sprint 🙂

  5. We played a round of this at work today, it was pretty great. I lead a bunch of Lego City Scrum workshops but it’s nice to have something quick and lighter in the tool box. At our discussions after we came up with a number of questions and ways to change\improve the game, but overall it was great.

    Most of our questions were around chance cards: Can one story have multiple problems attached? Can you use solutions anytime? Can you use multiple solutions on a single turn? If work is done on a story is it put in the done column right away or do you have to draw a chance card first?

    Thanks a lot for making this available!

    ToddS

    1. Hi Todd,

      Thanks for the good words I’m glad that you like the game. I developed it back in 2010 or earlier and it helped me on many Agile workshops and trainings.

      As for the questions, I usually say that one Story could be blocked by as many problems as you pull out. This is the real life: “shit happens” 🙂
      You can solve problems everytime the team can see on the table a Solution that could work. Again, every problem is a simplified case from the real life and every solution is a piece of wisdom that could work in several cases.
      Every time it has to be a discussion among players – if they believe in real life they would apply such a solution to such a problem case – then you are done and problem solved.

      Some of the Solutions could have a meaning of an extra action, like “involve intern and throw dices as you have one more man in the team for a day”.

      Anyway, keep it simple – the simplicity is what many people like in this game 😉

      Cheers,
      Tim

Leave a Reply

Your email address will not be published. Required fields are marked *