The Coin Game (now available remotely!) — a simple but effective way to demonstrate agility…

Steve Wells
6 min readFeb 7, 2021


Update: If you want to run this with remote teams or people who are WFH, let me know; I have built this as an app that you can run with single or multiple teams. Or, I can run it for you …

Note: Th online game allows you to change currencies…

I will start this by pointing out that this game is not my idea. I first saw it at Agile in a Bag in 2016 demonstrated by Sunil Mandra, but it was such a powerful demonstration that I have shamelessly pinched it and have used countless times since (while always crediting the source, obviously…).

This post might look quite long, but the game is actually very simple to set up and run, so do bear with me…

Here’s how it works.

The Game

You’ll need a set of coins of varying denominations. I’ve listed what I have in my set at the end of the article; this seems to work OK, but don’t feel it has to be exactly this.

Next sit a group of 4 or more people round a (empty!) table and give each of them a role in a typical “project flow”. As an example:

  • PO
  • Designer
  • Developer
  • Tester
  • Customer

Don’t worry too much that this isn’t how agile “projects” work — we’re just demonstrating one aspect of agile here; there are other games to demonstrate collaboration, co-creation, lean discovery, etc. etc.

Incidentally, I’ve often done this game in workshops where there are a number of these groups, and it really works; that competitive edge really brings the game alive and is really noisy and fun.

Having set up the group(s), you need to explain the rules. We will be simulating the flow of value from inception (e.g. PO in the above list) through each role (PO -> Designer -> Developer -> Tester -> Customer) by passing coins from one role to the next. “Work” is simulated by turning the coins over before passing them on. Value is “delivered” once a coin reaches the customer, and is easy to calculate — £5 means £5 of value!

There will then be 3 rounds using different delivery strategies

Round One: Batch

In this round, all the coins must be turned over by each role, before passing them on en masse to the next role, i.e. the PO turns all the coins over, then passes all coins to the Designer, who turns them all over, then passes them all to the Developer in one go, and so on.

I usually give a 2 minute limit on this round so that no value actually reaches the customer.

You can then ask ask questions around how they felt when turning over the coins (pressured, usually, as everyone else watches and offers helpful advice like “Come on! Quicker!”), and when they weren’t (bored and frustrated, usually, waiting for their turn). Save the best question of all until last, and ask the customer — “How much value was delivered to you from all that effort?”

Round Two: Iterative

In this round, coins can be passed on as soon as they have been turned over. Make sure you time this round to show how much more effective this is than round one. Teams usually deliver all the coins in about 1:30 to 1:45 with the set of denominations I use.

Again, ask questions after the round comparing the two rounds. Hopefully the participants will feel more engaged as they were constantly busy, and the customer will be happier at getting all his value delivered.

Round 3: Value-Driven

This round is the light bulb moment. Up until now, everyone will be thinking they haven’t seen anything new, and it’s all just a bit of a laugh.

So, now you tell the teams they have to deliver as much value as they can in 20 seconds. Let that sink in for a bit. Having taken up to 2 minutes to deliver all the value, they may think they are on a hiding to nothing. Give them some time — and a massive hint — to “sort the coins in any way you wish”. They should obviously, sort them to pass on the bigger denominations first. Do keep dropping hints until they realise this!

Start the timer, and see the sparks fly. Typically, they will deliver between £15 and £18 of the £20 in 20 seconds. Point this out, and let it sink again. This is where the light bulb goes off — in 16% of the time of Round One, where, let’s not forget, we delivered no value whatsoever, and about 20% of Round Two, we have delivered 75% to 80% — sometimes more — of the value!

80% more value in 25% of the time. It’s a powerful demonstration.

The De-Brief

I then usually draw 2 graphs to really emphasise the points made by the game. It is definitely worth drawing these on a whiteboard and explaining as you go along — I find it much more effective than just showing a slide or pre-rendered graphic.

Firstly, the value delivered over time, and how it tails off — this is how we delivered 80% of the value in the final 20 second round, by delivering the highest value items first. Hmm, sounds a lot like that “agile” thing, no?

If you draw the curve first, you can then add in the costs over time and show the point — X — at which the value we’re delivering is less than the cost of delivering it. At this point (at the latest!), we should stop, or at least pivot onto something that delivers more value. ( Apologies that this is quite badly drawn — the y-axis is “£” — value delivered, and the x-axis is “t” — time.)

Secondly, the reduction in risk by delivering iteratively (rounds 2 and 3) instead of building everything then delivering (round 1)

This graph shows that waiting until everything is done — Round One — is a huge risk (red hatching). If you take this approach and miss the deadline, you have spent all the money and delivered no value. The iterative approach reduces that risk to a small amount per iteration; whenever you stop development (after the first iteration) you have always delivered some value. And, of course, if you deliver the wrong thing, you’ve only wasted one iteration’s worth of effort and can pivot onto the right thing very quickly…

This is a useful point to make in highly regulated industries, e.g. banking — an argument against delivering highest value first is often “it all has to be delivered anyway, so why bother?”. If you can deliver 90% of some regulatory requirement before a deadline, that reduces the risk of fines, etc. enormously. The final few low-value, and presumably low-risk, items will likely be not used much anyway. Also, if the regulators come to inspect, they are likely to be more lenient if you have delivered 90% of what is required at the deadline rather than having 100% “dev-complete” or “in test”.

Coin Denominations

I use £20 worth of coins, in the following denominations:

  • £2: 1
  • £1: 7
  • 50p: 11
  • 20p: 21
  • 10p: 6
  • 5p: 4
  • 2p: 5
  • 1p: 18

I did try it for a while with plastic toy money, but I think the real coins work the best as they really hammer home that we are delivering actual value…

Note: getting all those coins in a good range of denominations is the hardest part of this game; don’t underestimate how hard it will be :-)

Originally published at



Steve Wells

Building online versions of agile workshops such as the No Estimates game, to see how close we can get to the face-to-face experience for remote or hybrid teams