An estimation game for sprint planning

Note: I haven’t tried this. I currently work in a team of one, which makes this a bit hard, but I’ve done a lot of group estimating in the past, I expect to do it again, and I frequently talk to people who do do this sort of thing.

This is a technique that I think would improve people’s ability to realistically come up with a set of tasks which can be achieved in a sprint or other work period.


  • You have a period of work (a sprint) and a set of tasks. You are trying to decide what tasks to schedule for this sprint.
  • You have some group of people responsible for estimation and some stakeholders in a room.
  • The stakeholders can decide what should get done as long as the estimators think that’s a reasonable amount of work.
  • There may or may not be overlap between estimators and stakeholders – it works the same either way.
  • You have some unit of estimation (it doesn’t matter what) and a predetermined maximum amount you expect to get done in a sprint. Deciding on this is out of the scope of this game.

The Game

You will need:

  • Your tasks nicely laid out in some space on a table
  • A lot of cards with numbers on them, corresponding to your estimation units. You’ll want enough that nobody is going to run out of any number.

The game is played as follows:

  1. For each task you have to estimate, each person puts a card face down on the task. It’s important that this is not seen so that everyone’s estimate is independent. I think this is probably the most useful part of this game and the one I’d like everyone to try even if you don’t try the rest.
  2. Once everyone has estimated every task, shuffle each deck and put it back on its task face up. Make sure you can’t see any card except for the top card.
  3. For each task, the  top card of the deck associated with that task is now your estimate for it. Come up with a set of tasks that fits within your budget given those estimates. Remove all other tasks.
  4. Now remove the top card from each deck. The new face up card is your new estimate for that task. Remove tasks of your choice until your new total estimate also comes under the total (this may not require you to make any changes). Note: You may not bring in cards you have previously rejected to “top up” any spare points.
  5. Repeat the previous two steps 10 times. If you run out of cards (you should, because if you have 10 estimators in the room that’s a very expensive meeting!) reshuffle the decks for each task and start over.
  6. Whatever tasks you have left at the end is your plan for the sprint.

What is this trying to achieve?

Basically there are a couple ideas in here:

  1. A group of people will tend to do probability matching for the size of a task, so the distribution of card draws is a pretty good predictive distribution for the size of a given task. This is particularly true with the blind draws as people have less social pressure to conform to the group idea of what the correct answer is.
  2. Each draw of the cards is then a simulation where you are asking the question “Will we succeed at achieving our goal?”. We always reduce our goal, so the answer is always yes for each simulation run.
  3. A smooth Bayesian estimate with a \(\beta(1, 1)\) prior gives the estimated probability of us achieving our goal after N steps as \(\frac{1}{1 + N}\), so after 10 steps we’ll have brought the chances (assuming a correct model) down to < 10%, which seems good enough for an estimation process.

Possible risks:

  1. There’s some vulnerability to bad actors overestimating or underestimating tasks without the accountability of public knowledge. It’s reasonably visible when this is happening, but not who is doing it. I recommend trusting your coworkers until this is obviously a problem – vulnerability to bad actors is better than good actors not being able to get correct answers.
  2. The simulation is far from perfect, due to a) The fact that people won’t probability match accurately and b) It doesn’t account for correlation very well (although shuffling helps reduce correlation).
  3. It’s a bit fiddly and people will get annoyed. On the other hand, it’s a lot less annoying than the sort of arguments that usually happen in these meetings.


This is a bit of a half baked idea, but I think it could work. It has a lot of useful debiasing features built into it, and despite its relative complexity I think it might actually speed up the process by reducing the amount of arguing and deliberation, while still speeding up the result.

Anyway, I have no capability to try this myself, but if you do, let me know! I’d love to hear how it goes.

This entry was posted in Uncategorized on by .

One thought on “An estimation game for sprint planning

  1. Pingback: Bee log for 2016-04-29 | DRMacIver's Beeminder Log

Comments are closed.