** Updated with links to better quality DoD images **
Name: Judgement Juggler.
An agility learning ball game, built on The Penny Game, that introduces estimates based on defects and dependencies to more closely simulate software development in an enterprise environment.
Estimate taking into consideration defects and dependencies (both internal and external). Additional learning of work in progress limits, intra- and inter- team communication, iteration planning, and finishing work based on a Definition of Done (DoD) at both story (or ball) and iteration levels. Can also be used to focus on process improvements using metrics, i.e. number of balls, time to complete, number of defects, etc.
½ hour to 1 hour depending on how many rounds you wish to perform.
Number of participants:
At least two teams with a minimum of 5 in each team (10 people total). Three teams or more work best. Teams do not need to have an even numbers of participants.
- Butcher’s paper
- A pen, e.g. sharpies, for each team
- Balls (one colour or distinguishing mark for each team) – enough so that each team has 25-30 balls, see example of bag of balls below.
- 2 x bags (or bin/buckets) for each team. I prefer to use fabric shopping bags with the rectangle bottoms as they can stand up but add an extra dimension to the game when they fall over.
- Definition of Done (DoD) handouts (see below) x 3 for each team
Example of bag of balls:
Definition of Done (DoD) Handouts:
Note: the bold is the learning change between each round. See “Variations” below to see how you can change this up if the teams are doing too well.
In each team’s bag place the following:
- Round 1 DoD only – don’t show the teams the Round 2 or 3 DoDs just yet.
- 25-30 balls of the same colour
- An additional bag – labelled “DONE BAG”.
Make sure that there is enough room so that participants don’t have to climb under desks or over chairs if the balls go everywhere.
Draw up a grid on the butcher’s paper, with a swim lane for each team, and a header to write in the rounds. Example:
Divide the group into teams of 5 (min. 5 people per team).
Get the teams to assign a “Scribe”, “Runner”, “Feeder” and “Collector” – they will ask what these roles mean – don’t worry they will find out shortly.
Give each team their bags.
The game is run over several rounds, with each round introducing a new concept.
Each team is to read the Round 1 DoD. As part of this round they should define a process that each ball travels through from the Feeder’s BACKLOG BAG to the Collector’s DONE BAG – as per the DoD the ball cannot be thrown to the person next to you. Give the teams 1 minute to sort this out.
Make it clear to the teams that the DoD must be adhered to. If it’s not “done”, it doesn’t count – i.e. if it’s not in the DONE BAG or not everyone has processed it, then it’s not done. If a ball is dropped it must go back to the start of the process for “triage and re-prioritisation”.
Get the teams to estimate how many balls they can process in 1 minute. Ask the Scribe to record the estimate on the butcher’s paper.
The Runner’s role is to collect the “defects”, i.e. the dropped balls. If recording defects, they may be in charge of tallying the number of defects in the round.
At the end of the round (when a minute is up) get the teams to count how many are in the DONE BAG (not those that are still being processed). The Scribe should record this on the butcher’s paper underneath the estimate.
Put all balls back into the BACKLOG BAG and reset the teams.
Observations / Tips:
You may need to run this round a couple of times to make sure that teams have got it.
Before moving to the next round you may want to ask the teams the following:
- Why is there a variation between estimate and the actual?
- What happens if teams exceed their estimation?
- What if they under deliver?
- What is acceptable variation?
Before starting this round tell the teams something like:
“Due to your hard work and the great value you have been producing you, as a team, have decided to review the DoD and have come up with the following…”
Give the teams the Round 2 DoD, explaining that now they can process multiple balls at a time.
As before, make it clear to the teams that the DoD must be adhered to. If it’s not “done”, it doesn’t count. There will most likely be more defects (balls dropped) this time. As in Round 1, if a ball is dropped it must go back to the start of the process for “triage and re-prioritisation”.
Get the teams to review their process and record how many they think they can process in 1 minute.
Conduct the game.
After 1 minute, record the actuals.
Observations / Tips:
As more balls start to fly around the room, suggest that the teams are experiencing more defects and that they should account for this in their estimates.
You may want to run this round a couple of times. In between iterations get the teams thinking about their work in progress (WIP), and how having too many balls in the circle may cause more defects.
Again start this round by updating the DoD. Give the teams the Round 3 DoD, explaining that now the teams must not only process all their own balls, but must also process a ball from another teams DONE BAG (i.e. a ball that has been processed from another team). The job of the Runner is to collect the ball from the other team and bring it back to the team.
Make it clear to the teams that the DoD must be adhered to. If it’s not “done”, it doesn’t count. This is especially true for this round. If the Iteration DoD is not “done”, that is, if the team does not have a ball from another team in their DONE BAG, they will get zero for the round.
Get the teams to review their process and record their estimates.
Conduct the game for 1 minute.
Observations / Tips:
This is where you will start to see some interesting behaviour from the teams. Some teams will work together and re-position themselves so that their DONE BAG is near another team’s BACKLOG BAG, and vice versa. Some teams will work out that they can make another team get zero if they take a previously processed ball from the teams DONE BAG (i.e. a team processes a ball from another team, only to have that ball stolen from their DONE BAG, leaving them unable to complete the Iteration DoD and record zero at the end of the iteration).
You may want to run this round a couple of times. In between iterations get the teams thinking how having to rely on another team to finish their work before you can finish yours affects your estimates.
- In Round 3, instead of requiring just one ball from another team make it 5 or as many as you can process.
- In Round 3, make other team’s balls worth 2 (or more) of your own to make the teams want to take more from other teams.
Deciding a Winner:
Depending on what you are trying to teach the team you can define winning in a number of ways. I suggest that you do not let the teams know how to “win” until the end of the game. That way you can change your mind if you want to, and also observe how teams set their own criteria for winning without knowing what the “real” way is. For example, teams may want to process as many as they can, but the “winner” may be the team with the best estimate to actuals ratio, or the fewest defects (if you want to do this make a tally of the defects so that there is a count to base the winner on).
Tip: To make it easier to judge a winner, at the end of each round calculate the running total for each team, the estimates to actual ratio (and if required defects), and record it on the butcher’s paper.
Some of questions you might ask the group after the game include:
- What did you learn?
- How did defects affect your estimates?
- How do WIP limits affect your estimates?
- What do you do if you can’t control your dependencies, how do you account for that in your estimates?
- What makes an iteration done? How does this affect estimates?
- Was there too much speed and not enough processing? Or was there value at a sustainable pace?
- If you are in competition – were you able to do more?
There are many different ways that this game can be run depending on what you are trying to teach the team. To get the best learning from the team it is best just to focus on a single stream, such as estimates. That way the team can focus on estimates and try and apply that lesson to their work.