Agile 101 – How to play the game

Get insights in your inbox

Whilst there are lots of ways you can vary the game
depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.

Contents
Inside each tin you will find a 20-sided dice and a collection of cards. You’ll need to keep score as you go so make sure you have pen, paper (or an app!) to do this.
In the deck, there is one black, double-sided Rules Card containing a list of bullet points to be referred to during play.

Character Cards (Green)
Start by deciding which character you’ll each be playing, you’ll need one Product Manager and one Delivery Manager; everyone else is a Developer.


If playing as a team of 8+ and there aren’t enough cards for everyone, you can keep adding Developers, but note in the rules above, each additional player is a ‘-2 skill’. This means you must take ‘2’ away from every score they roll with the dice.
Story Cards (Purple)
These are the most complex cards in the deck; think of these as your backlog. They are available to your team at the start of the game and the challenge is to decide in which order to tackle them and how to organise yourselves in order to deliver the outcome.

Event Cards (Orange)

You can turn over a random event card any time during a round (explained below), after you’ve planned the story cards you’ll be working on. Depending on the nature of the event, the event card will require either the Delivery Manager or Product Manager to roll.

Rounds
A round is controlled by the number of developers in your team, with each developer getting one roll of the dice per round. I.e if you have four developers, the maximum number of story cards you can plan to do is four. If you want to have two or more developers working together, combining their scores and de-risking the development, you must begin the round with fewer story cards.
Roll to deal with an event card at the end of the round, just before you roll to release.
N.B. If you’d planned to pair on something but the first developer to roll, scores the full amount needed, the second developer must still roll against the original story. You can’t take a new story card for the round as the task has been completed as a pair.
Once you have developed your story cards, deal with the event card before moving on to releasing completed work. The required release scores on the cards are individually quite small, but any released together should be added up. The Product Manager then gets a single roll for releasing at the end of the round. If they get the required score, increment your user total by the successful impact, and if they fail, increment or decrement by the failed impact.
The impact varies – sometimes it’s good, sometimes it isn’t; there are opportunities to greatly increase and decrease the number of users you have with just one roll of the dice.

Bug Count
If you fail to get the required developer score on any story card you can choose to return it to the backlog and attempt it in a later round. Or you may choose to still bank it for release, but the difference in scores will be added to your ‘bug’ count. So, if the required dev roll on a card is 10 or more and you roll an 8, you may decide to bank it anyway and increment your bug count by 2.
Be mindful of your bug count – once it hits 5, you can’t release anything at all until you bring it back down. A developer can work on those bugs instead of another story card in the round; then whatever they score is deducted from the bug count.
There are a number of other ways to reduce your bug count, so familiarise yourself with the story cards in the backlog.

Users
If you’ve played a D&D game before, the idea of critical hits and critical fails will be familiar. In this game, whenever anyone rolls a straight 20, you will be awarded an additional 10,000 users. If you roll a 1, you will lose 10,000.
Any rounds which result in zero user impact, you will lose 10,000 users.
In later posts we’ll explore the different ways you can use the game. Small and large groups, modelling different delivery frameworks and adapting for your team and organisation. We’ll also look at the learning objectives designed into the game by default, how to draw those out from the teams as you play, and how to adapt and develop the game play for your own learning objectives.

Agile 101 is available to purchase now (select “I would like to purchase Agile 101”). GAME ON!