Alternatives to Planning Poker
Planning poker is a common way of doing story point estimation. It has some advantages but some problems too.
What is planning poker again?
Planning poker is often used in teams doing Scrum (though is not mentioned anywhere in the Scrum team, despite popular belief). It was popularised by Mike Cohn in his book “Agile Estimating and Planning”. It is a technique for a team to collectively come up with story point estimates for a number of user stories. (Not sure what that means? Read my guide to story point estimation here).
If you’re already familiar with planning poker, feel free to skip straight down to “planning poker alternatives” below. Otherwise, keep reading for an explanation of how it works and why people do it.
How does it work?
Let’s say you have a team of seven or eight people, who have a dozen or so user stories in their backlog that they would like to estimate. To do it via planning poker, each person in the team will have some method of providing a number. That is usually via a deck of planning poker cards, though you can also use an app on your phone.The numbers are usually Fibonacci numbers, which is a series where each number is the sum of the two previous numbers. So it goes 1, 2, 3, 5, 8, 13, 21, and so on (it usually doesn’t go past 21 because stories should never be that much bigger than other user stories).
The numbers are usually Fibonacci numbers, which is a series where each number is the sum of the two previous numbers. So it goes 1, 2, 3, 5, 8, 13, 21, and so on (it usually doesn’t go past 21 because stories should never be that much bigger than other user stories). The team picks the first story from the list and discusses it for a little while. Remember, a user story is written as a problem statement. The team is now thinking of how much work it would be to solve that problem statement, i.e. to implement a solution that meant the behaviour described in the story was achieved.
Planning Poker estimation
Once the team is ready to estimate, each person chooses a number from their deck of cards (or their app or whatever). They do this silently. Then each person reveals their estimate at the same time.
The reason it is done like this is that one person’s estimate should not influence another person’s estimate. If each person provides their estimate in turn, then the first person might choose a large (or small) estimate, that might make some other people change their mind and thus their estimate. The process is intended to allow each person to provide their own honest unbiased estimate.
Of course, the numbers are often different, which means another discussion kicks off. There is sometimes then another round of estimation. Some Scrum purists insist that the team continue rounds of estimation until everyone comes up with the same number. I think this is madness, and encourages the very thing planning poker was meant to prevent: people “bullying” others into agreeing with their estimation.
I think it should continue until a consensus is reached, which is usually very clear (and NOT the same thing as conformity, i.e. everyone has the same estimate). If there is a range of estimates consisting of 2, 2, 3, 3, 5, 5, then the estimate is a 3. It doesn’t have to be an exact average, but a median works fine. And it doesn’t have to be mathematically precise. Estimates are essentially informed guesses. The estimation process is not precise so the estimates will never be, and that’s ok.
So why look for alternatives to planning poker?
You might be wondering why you would want alternatives to planning poker. It’s not a bad system, but there are some problems with it.
It is slow
It can take a long time to do planning poker estimation. I’ve seen sessions go for two or three hours, and it’s not fun. Throwing down cards is fun at first but it gets old really fast. Bickering over whether something is a 2 or a 3 is boring and frustrating and not a valuable conversation.
The poker is distracting
Arguing over whose card is right or wrong can distract people from what is the much more valuable conversation: the discussion about the solution. Especially why someone feels something is a two or a three as opposed to something else.
It can give a false impression of estimates
Some people think if you do this fancy game, then the estimates themselves suddenly become more accurate and therefore valuable. This is completely false. Planning poker is a good way of reaching a consensus on estimates. That doesn’t mean they are accurate. It’s very possible for a group of people to be wrong about something (especially something notoriously difficult to estimate like software development complexity).
Planning poker alternatives
There are some alternatives that you can try if you are getting sick of poker, or you think it could be better.
Instead of numbers (Fibonacci or otherwise), you can do T-shirt sizes. Small, medium, large, extra-large. This gives you a smaller range of possible estimates, which means you will get fewer disagreements and less variation. You might think that the estimates will be less accurate, but I don’t think they will be. I find rough t-shirt sizes to be good enough. You will need some baselines for these sizes; just use previous stories or features. (I actually like to do t-shirt size feature estimates and no story estimation, more on that later). You could also just use a smaller set of numbers (1, 5, 8, 20) or something as proxies for t-shirt sizes. But I like the fact that numbers aren’t used here. It makes it more clear that these are not measurements and are not accurate.
For the actual estimation, you can use the poker technique, or Affinity Mapping (see below).
You might be familiar with Affinity Mapping from Sprint Retrospectives. It is a technique for grouping similar items together. Start by creating a series of “tags” or “buckets” on the table: these could be Fibonacci numbers, or t-shirt sizes, or categories, or anything. Then you lay the stories down on the table as cards or something similar. Next, the team collectively moves the cards into the buckets to represent that as an estimate.
This is an interesting and unusual technique that not many people know about. It is an effective way of estimating a large number of stories in a very short space of time. Start off by defining your benchmarks (Fibonacci numbers, t-shirt sizes, etc). Create buckets on the table as per Affinity Mapping.Next, each person is randomly assigned a set of stories to estimate (maybe deal the stories out as if they were a deck of cards). Then, taking turns, each person silently estimates by placing a card on one of the buckets. Alternatively, a person can move a card from
Next, each person is randomly assigned a set of stories to estimate (maybe deal the stories out as if they were a deck of cards). Then, taking turns, each person silently estimates by placing a card on one of the buckets. Alternatively, a person can move a card from one bucket to another, if they strongly feel it is an incorrect estimate. Keep doing this until all the cards are estimated. If a card is moved twice, take it off the table — it will need a separate discussion after the meeting since there is wide disagreement on its estimate.
The advantage of this technique is that a team can estimate a lot of stories in a very short amount of time. I would use it if you are asked to estimate 100 stories or similar (though I think if you are, that is a sign of a bigger problem — you should only estimate one or two sprints’ worth of stories in advance). The disadvantage of it is you miss out on what is often the valuable part: the discussion around the stories.
Some people take a more extreme position. They think we should get rid of estimates altogether! This is a movement that is often identified by the corresponding Twitter hashtag #NoEstimates. It was started a few years ago by someone called Woody Zuil, and is mainly championed by an Agile coach named Vasco Duarte. If you want to try this, it’s easy: don’t just scrap the poker, scrap the estimating too. You can then do a couple of things:
- put an average estimate on all the stories (use a historical average, either total or rolling average of the last three sprints)
- forget points and just use the number of stories for planning purposes
- forget story planning altogether and just estimate by features, probably using t-shirt sizes / number of sprints.
For what it’s worth I fall into the last camp. I don’t feel story estimates are very valuable, though high-level feature estimates are useful for release planning (and I have found they are often as much or more accurate than a total of story point estimates).
NoEstimates is a complex and very controversial topic, and deserves a blog post in its own right (possibly coming soon!).
You can try any of these and see what the team thinks. Make sure to consider these as experiments, and to gather the data (does the team feel it is better than poker? Did the estimates turn out to be more valuable?)
Remember that the most valuable thing that happens in an estimation session is usually the conversations around the solution, not the actual estimate numbers.
This article was originally posted on my blog at www.extremeuncertainty.com