Skip to main content

The Scrum Value Simulation

But please don't call it a game. Call it An Interactive Simulation on Optimizing the Creation of Value.

At Jeff Sutherland's CSM Course in Zurich, I witnessed him lead the class through Joe Little's Scrum Penny Game. It teaches the importance of small batches and optimizing the whole. I was really intrigued by the game, and thought it had much more potential, so I revised it and tried out the first incarnation at the Open Space in the Scrum Gathering. I wanted to see a) if the game (and especially the revised game) had the same impact on the assembled experts as it did on me, and b) get feedback for improved or alternative versions.

I wanted to emphasize principles that management could implement to improve value creation:
  1. Process Small Batches (unchanged from Joe)
  2. Remove Impediments
  3. Do Less (but do the right thing!)
So I set up the game as follows:
The Players:
  • Customer: sends the batch of coins to the workers, accepts (by touching) the received coins from the last worker.
  • Customer's Boss: Measures the time elapsed time between between sending out the first coin and receiving a) the first value (coin) accepted and b) all coins accepted.
  • Workers: Each worker receives a batch of coins, flips them, and moves the bath to the next worker
  • Efficiency experts: measure the time "their" worker spends flipping coins.
I deliberately identified the timers as 'efficiency experts' rather than 'managers.' Better not to antagonize the people who will influence the adoption of Scrum... ;-)

The Props: per team, 20 coins, consisting of
  • 5 quarters (25 cents each)
  • 5 dimes (10 cents)
  • 5 nickels (5 cents)
  • 5 pennies (1 cent)
  • Each efficiency expert and the customer's boss need a stopwatch with a lap split. Most cell phones can serve this purpose.
(During the briefing, I do not mention the values of the coins).

Constraints: Just so that the game is not too easy, there are a few constraints:
  1. All workers work with their left hand only.
  2. A worker may not combine coins for processing (added this one during the game)
  3. A worker may only pass on a complete batch.
  4. The moderator will specify the batch size.
We played several rounds. As there were only enough people for one complete team, We did some things sequentially, which I would have preferred to do concurrently (with the teams in competition with one another).
  • Round 1 - Lot of 20 (well 19 actually)
  • Round 2 - Lots of 10
  • Round 3 - Lots of 5
  • Round 4 - Lots of 5 without constraint on using one hand.
  • Round 5 - Reduce total volume. Customer selects the 10 coins with maximum value.
(Note: I only entered the totals for the last round on the table below).

Perform in Small Batches

Round 1 establishes the baseline. It also established competition between the team members (the one lefty was very proud that his time was the best). Note that the sum of the individual times != the total time measured by the customer's boss. Some workers blamed this on the slow reaction of the customer to accept the coins. There were also gaps because the measurements don't account for transit time.

Round 2: Before starting, the team noticed that a coin was missing. This was not intentional, but a great addition: Where is the missing functionality? What does this say about acceptance testing? This round showed the improvement of reducing the lot size from 20 19 to 10: Processing Time went from 1:41 to 1:03, a 38% reduction. Although that 3 of 4 worker's times were slower in round 2 than round 1, the time measured by the customer was substantially better.

Round 3: There was some disbelief about the effects of the batch size, so the third round was made with smaller batches still: 5 instead of 10. Individual performance was about the same, but the customer time improved again, declining to 0:43, a 32% reduction from round 2.

At this point, the team accepted the importance the first principle: produce in small batches.

Remove Impediments

I asked the team if anyone noticed that they had one hand tied behind their backs and pointed out the rules are there for a reason, but improving performance is not usually one of them.

Round 4: Same configuration as round 3, but team members may use both hands. Time to produce full customer value: 33 seconds, a further reduction of 23% from the previous round.

Do Less, but do the right thing!

I asked the team how much value they had produced. The sum of all the coins was $2.05. I asked the customer to pick the 10 coins with the most value (the quarters and dimes). This reduced the processing time a further 30% (down to 23s), but only reduced the value delivered by 15% (to $1.75).

As I write this, I realize that if the team had processed the pennies and nickels instead of the quarters and dimes, the value produced would have been $0.30.

Summary and Discussion

After playing 5 rounds, we had a spirited discussed on the lessons of the game and other lessons which could be learned from the game, and how to use the game to address other issues, such as:
  • the problems of a hand-offs in a phased model
  • self organization
  • swarming
  • rivalries between team members and teams
  • impact of bonuses
  • tension between optimize team and optimize self
  • need to release earlier than planned
  • what happens if someone is pulled out of the team
  • use different activities, some of which are harder than others
 Thank you

I would to thank everyone who came to the game for their help and energy, and above all for the great discussions afterward. There will be a picture here in a moment. If you use this game (uh, simulation) or modify it do drive home some other points, please leave a comment ( or a link to your own blog) so that this simulation can develop its full potential! Thanks.


Sameer Bendre said…
Peter, I was very happy with the way things shaped up during the game. It was FUN with the competitive element Brian Bozzuto brought into the game and the explanations by you and @srob were eye-opening. Everyone in that room njoyed the game and contributed their experience and learning.
Thanks again for organizing this and your valuable inputs during our meeting.
- Sameer Bendre (@Bendre)
Karen Greaves said…
Hey Peter, really enjoyed this game in Open Space. Will give it a try in my next newbie Scrum training in April and let you know what happens.
Karl Scotland said…
Hi Peter,

I used the Penny Game to kick-off my Kanban Deep Dive at the Scrum Gathering for the reasons you describe. I missed the OpenSpace opening - if I'd know you were doing this I'd definitely have come along!

I really like your variation. The one thought I had was that if you're going to be specific about calling it a simulation, why also include Scrum in the name? Its not really about Scrum but about value flow? So how about "The Value Flow Simulation"?

Peter said…
@Bendre, @Karen

Thank you very much! I used this game in a CSPO course this week. Lessons learned:

1. This game is immensely powerful. There are so many lessons that can be extracted from the game. Too many, actually. It's important when doing the game to decide and communicate clearly which messages you want to get across.

2. Don't do too many iterations. After a couple iterations, people get numb. 3 or 4 is probably the right amount. 5 was too many.

3. Main disadvantage: Like the Ball Point Game, this is about production, not knowledge creation. (Yeah Karl, I hear you ;-) ).

For the product owner, I will probably focus on these messages:

1. Produce Small Lots
2. How the customer role changes as the lots get smaller
3. Prioritize & Do Less

(This means I can do away with the efficiency experts)

For a Scrum Master course, I would probably focus on:

1. Smaller lots
2. How individual performance and team performance are (not) related
3. Removing impediments.


Unknown said…
I did this last week in my inhouse Scrum training with some modifications. Check out my post here:
Peter said…
Great alternative Karen, I'm going to try it out with my next group!

You can find Karen's version more easily by following this link: The Scrum Penny Game – a modification
Unknown said…
Such a simple game that demonstrates the benefits of smaller batch sizes! Thanks for the description! I posted a review on my blog at http://
Peter said…
Should have mentioned long ago - I now prefer Karen's version of this game. I like the addition of 2 minute iterations - the increase in value produced per sprint can be really dramatic and makes the game more Scrum like. Without the iteration it's more of a flow simulation.

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…