During a previous meetup, I presented the Scrum@Play which is a new game to raise awareness about Scrum and Story Mapping. In order to be able to animate it yourself, here are the rules of the game of this first version and all the necessary to print your complete game.
Scrum@Play purpose two distinct phases: story-mapping and scrum.
Preparation of required materials
To begin, you will need to print the game board and all cards. Don’t forget to print on both sided.
You will not forget to cut the cards. If you have the material available, I recommend you to laminate all the elements.
With that, you will need to find three small chips and two dice to have a complete game.
* To simplify the animation, I advise you to have real dice and not an application dice because the download and the installation can take time.
Launch of Scrum@Play
To start the game, we will work by an incremental explanation of the game and explain that at our participants. It’s dangerous to explain everything upstream because the participant will be in the confusion confusion later.
We will be arranging the board with three chips on it, the two dice on the side, and the cards like in the picture below:
The facilitator explains that the game will be played in two different parts.
He will ask the team to determine who will be scrum master and who will be product owner. The facilitator will take the opportunity to sensitize participants to both roles. The other participants will be developers.
Let’s do a simplified story-mapping
During this first phase of the game, the facilitator will teach the participants to do a story-mapping to organize and prioritize the work.
Participants will take “Epic” and “Items” cards and place all Items cards under corresponding Epics cards.
Here is an example with two different “Epic”:
Now that this work is done, the facilitator will explain the notion of MVP (Minimum Viable Product) and purpose to the participants to split the items in half.
Top: the required items to deliver the product (1st MVP release)
Bottom: items that can be realized later in a second release
The notions of prioritization like MoSCoW or ROI are deliberately not used to stay in a simple context to understand.
Here is the result on two Items:
Launch of a first sprint
The facilitator will explain all the elements proposed by this game board.
The game board
The game board has three distinct areas:
- a circle with 5 boxes representing 1 week sprint
- a user satisfaction indicator
- a motivation indicator of the team
The facilitator will explain what a sprint is and this concept of iteration in scrum. He will remind that the two-week sprint is the most recommended but that it is possible to do sprints from 1 to 4 weeks according to the scrum guide.
When the player completes the turn of the box 5, he will go to the box 1.
Make a small kanban board
To have a good vision of the progress, the facilitator will propose to the participants to make a small kanban board on a A3 sheet on which the team will be able to dispose these “Item” on it.
The facilitator will explain to the participants the interest of this board.
Here is a simple example:
The two dice
Both dice will be thrown each turn. The total of the two dice will determine the achievable work of the team (the total of story point achievable).
Cards or both indicators (customer satisfaction and team motivation) can change the total of story point achievable.
The cards “prerequisites”, “items” and “bug” are the cards to realize that will have story points written on it.
The facilitator will take the opportunity to explain this notion of “story point”.
These boxes range from +4 to -4. Actions on the cards will change the customer satisfaction considered essential in an agile product.
If you have -2 in customer satisfaction, then you will have to remove -2 to the total of the dice obtained each turn.
If you have +2 in customer satisfaction, then you will have to add +2 to the total of the dice obtained each turn.
These boxes range from +4 to -4. Actions on the cards will change the motivation of the team considered essential for good productivity.
If you have -2 in the team’s motivation, then you have to remove -2 in total of the dice obtained each turn.
If you have +2 in the team’s motivation, then you will have to add +2 to the total of the dice obtained each turn.
These cards are no longer used in this phase of the game. They allowed to work on the story-mapping.
These cards are the user-stories to be made during sprints. They indicate the mandatory pre-requisites and the story points needed to achieve them.
It is impossible to make an Item card if the prerequisites written on the card are not in the “done” column (prerequisites have numbers).
Here is an example of an item card to understand:
These cards are non-functional requirements that allow to set up the technical base (some coaches are not fan). Some prerequisites help to secure the environment and are not mandatory.
The participants have all cards at the start of the sprint.
The bugs cards are to draw only when an action requires it. Each bug card explains the constraints it causes that participants have to respect.
Participants will draw an action card each turn. It explains real events experienced by scrum teams and the consequences of them.
Review et retro cards
Participants must draw them at the end of the sprint at the end of the turn in box 5. They must respect what is written on these cards.
A sprint of 5 rounds
Each sprint (iteration) will do 5 rounds. Participants will roll the dice each turn and move the chip from one box to another.
The participants will define what they think to be able to achieve in the sprint before even rolling the dice. They will take into consideration the prioritization performed during the story mapping.
The participants will put what they think they can achieve in the “Todo” column of the kanban board.
On the first sprint, the facilitator will explain this notion of sprint planning which allows to start a sprint and the notion of commitment. He can also explain this notion of story points.
When this sprint planning is over, participants will draw an action card. They will have to read it and respect the actions imposed by it.
Then they will roll the dice to know the total of story point achievable (don’t forget to remove or add points according to the cards, customer satisfaction or motivation of the team). They will pass the cards from “Todo” to “Done” by not exceeding the total of story points.
If there are still some story points to finalize a card, the participants will put the card in “in progress” and will note on it the story points remaining to be able to put it in “Done”.
From 2nd round to 4th round
These rounds are classic. It will start the round by drawing an action card and throwing the dice.
The beginning of the 5th round is identical to the previous ones: action card and roll of dice.
When this is done, the team will do a quick review between them: what the team have finished during this sprint. They will also take a “review” card on which there are instructions to follow.
And finally, the team will make a fast retro between them: determine how we can improve the next sprint. They will also take a “retro” card on which there are instructions to follow.
On the first sprint, the facilitator will explain this notion of sprint review and retrospective that allows to finish a sprint and the notion of continuous improvement.
And the other sprints
Participants with all the explanations in hand will be able to do 3 or 4 additional sprints at their rhythm.
Now, you know everything to animate this fun serious game very useful to raise awareness to scrum.
If some explanations are not clear, don’t hesitate to ask me and this documentation will improve according to your different feedbacks.
Check our commitment
It is interesting to propose a simple board to compare the commitment of the team and the velocity achieved at the end of the sprint.
Here is an example of a simple table:
Scrum@Play is licensed under Common Creative. Here are some answers that I can give you on the right to exploit the game:
- This game is usable in business
- This game can be used during your training (even paid) without having to pay anything back
- Any use of the game in any context is permitted without prior agreement
- Any communication is authorized without prior agreement
Here are the few restrictions made currently:
- We are blocking the fork for the moment so that anyone wanting to contribute to its evolution participates in it with us.
- We ask that the name of the authors be remain: game created by Judicaël Paquet (Myagile Partner) and improved for a V1 by Dhia Eddine Ben Sheikh and Philippe Sellem.
However during training / workshop / meetup, if the coach wants to test something in order to give us his feedback on his attempt to slightly modify the game, he is fully authorized to do. The test and learn is recommended by our team.