Scrumchkin Instruction Guide — Shu Level
--
If you downloaded or bought Scrumchkin, you might want some help taking the most out of your sessions. And although there's an Instruction Guide available, this post aims to be a "read as you play" guide so you don't have to memorize the whole thing.
Defining Roles
Ok, we need at least 5 people. 9 at most. Plus, we need a ScrumMaster and a Product Owner.
I often ask everyone to point their fingers up, count to three and ask them to point to the ScrumMaster. And then repeat the process to define the Product Owner. It's fun and we avoid wasting time discussing who should take the role.
If there are people who are actual ScrumMasters and Product Owners, I suggest them to live new experiences during the game. Although it might seem illogical at first, being on a different role helps to create empathy between team members and foster a broader understanding of the whole flow.
The ScrumMaster
The ScrumMaster can execute the following actions:
- Draw a card
- Give a card
- Take a card from a Dev Team member and give it to someone else
- Remove an Impediment
The Product Owner
The Product Owner can execute the following actions:
- Discover a new Feature
- Reveal the Business Value of a Feature
- Reprioritize the Backlog
- Gather customer feedback
The Dev Team
The Dev Team members can execute the following actions:
- Draw a card
- Play a card
- Estimate a Feature
Discovering the initial Product Backlog
The initial Product Backlog consists of 5 Features. The first 2 are both estimated and have their Business Value uncovered. The third one is only estimated.
I suggest you to let the Product Owner reveal the feature cards and the Business Value cards while a Dev Team member reveal the Size cards as it helps to insert them into the game world.
After running a few sessions, you might want to try some tweaks and variations.
Committing to a Sprint Backlog
A Sprint has 5 days, and during each day every player can execute two actions. There are Work cards numbered as 1, 2 and 3 Work points. And that's all the information they'll have to define their first Sprint Backlog.
By the end of the Sprint, some feedback cards may appear on the table, according to the following formula:
Delivered Features minus Undelivered Features
Don't worry, we'll get back to the Feature Cards later.
After the team decides what's in their Sprint Backlog, they take its cards and set them apart from the Product Backlog.
Running the Sprint
There's no turn order.
There's nothing forbidding the players to show their cards to each other.
There's no rule telling them about playing two actions in a row.
Do you know why? They're a self-organizing team. And as a facilitator you'll get to see this process occurring all the time. If you have a keen eye, you'll be able to ask some very powerful questions about their behaviour and decisions.
Doubts about rules and team decisions are great conversation starters. And conversations are the point of this game, don’t be afraid to interrupt the game and start them.
A day is over when everyone played their 2 actions. The Sprint is over after 5 days.
If the team managed to deliver all the planned features, you can let the Product Owner or the Dev Team spend 2 actions in order move the first Feature of the Product Backlog into the Sprint Backlog.
Orange cards are instantaneous. They are played the moment someone draw them, and it counts as a single action.
Bugs take precedence over any feature. They're blockers and while there's a bug on the table, nobody can work on anything else.
Technical Debt stays on the table and affect every feature. The team must decide when's the right moment to tackle the Technical Debt to remove it from the table.
Sick Days are actually Sick Weeks. Whoever draws this card can't execute any actions until the end of the current Sprint.
Impediments are total blockers. Nobody can do anything until the ScrumMaster removes it from the table.
But hey, we have good cards too! There are two cards that also stay on the table and are cumulative:
Automated Tests makes every bug fix a little bit simpler. As these cards start to take some table space, the team start to sow the benefits of continuous improvement.
Continuous Integration helps the team to eliminate Technical Debt. And as the Continuous Integration system is improved so does the ease to eliminate this annoying Technical Debt.
However, these green cards aren't free. You need to spend one action to play them. It makes sense, right? As in real life, Automated Tests and Continuous Integration don't come from the sky (although they often run in the cloud!).
Gathering Feedback
After the end of the Sprint, the facilitator does a simple calculation:
Delivered Features minus Undelivered Features
This is the number of Feedback Cards that will be available to the Product Owner during the next Sprint.
The feedback cards aren't revealed right away; the Product Owner needs to spend one action to gather each Feedback Card.
Feedback Cards are kept on the table and affect the Business Value of certain features. They'll probably impact the Product Backlog prioritization, which will consequently give some homework to the Product Owner.
Pro tip: As a facilitator, you might want to choose which Feedback Card you'll give to the Product Owner, since some will have more impact and therefore start richer debates.
End of the Game
Scrumchkin doesn’t end. Everybody wins if they learned something while having fun, and everybody loses if any friendship was ruined during the process.
Art is never finished, only abandoned. — Leonardo da Vinci
The facilitator must feel when the game becomes more mechanic and less noisy. This is where it ends. In my experience, most groups reach that point somewhere during the 3rd Sprint, but that’s definitely not a rule.
It’s nice to spend 20 minutes doing a little debriefing so everyone can share their insights and ideas of experiments to do in real life.
By the way, have you tried the Debriefing Cube?
That's it! I'll write some "Ra level" posts in the weeks to come.
Game on!
