Alternatives to Planning Poker
Planning poker is a common way of doing story point estimation. It has some advantages but some problems too. A lot of people think that Planning Poker is the only agile estimation technique. But that’s not true! There are some alternatives to Planning Poker out there. Let’s see what they are.
What is planning poker again?
Planning poker is often used in teams doing Scrum (though it is not mentioned anywhere in the Scrum guide, 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).
So it’s a very popular Scrum planning method. It’s often used with other backlog management approaches such as user story mapping, and velocity tracking in agile. 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 product 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.
Planning Poker uses Fibonaocci numbers, based on the Golden Mean ratio
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]
So now let’s see how the actual estimation works.
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.
Planning Poker is a common Scrum estimation method
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 Scrum poker, possibly other relative sizing techniques or agile planning tools. Planning Poker is not a terrible 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.
Throwing fingers
This is a simple pointing poker alternative. Instead of flipping cards or revealing Fibonacci numbers on a phone app, each person just raises their hand with fingers raised, from one to five. This won’t give you Fibonacci numbers but that’s ok. If you really want to convert them, you can (e.g. you can make four fingers into an estimate of 8 points, and five fingers an estimate of 13 points).
This isn’t too different from poker but it’s a slight change and is a bit faster because people don’t waste time playing with or searching through their cards. (I find the damn cards always go missing as well, so it solves that problem too!). If you want to take it a bit further, you can have half-points by people holding up half a finger.
T-shirt sizing
Instead of numbers (Fibonacci or otherwise), you can do a T-shirt sizing method. E.g. small, medium, large, extra-large. This gives you a smaller range of possible estimates, which means you will get fewer disagreements and less variation.
Tshirt sizing is a popular scrum poker alternative
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.
T-shirt sizing is a bit quicker and easier than Planning Poker, though they aren’t numbers. And often they will need to be (e.g. if you want to use them in a WSJF / Weighted Shortest Job First calculation). In which case you will need to turn them into numbers anyway.
For the actual estimation, you can use the poker technique, or Affinity Mapping (see below).
Affinity Estimating / Affinity Mapping
You might be familiar with Affinity Mapping from Sprint Retrospectives. Affinity Estimating 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.
Silent sizing
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.
Wideband Delphi technique
Some teams use something called the “Wideband Delphi technique” in agile project management. This was a popular approach in project management circles in the 1980s.
In this consensus-based estimation method, a facilitator proposes a task or feature to a group of experts. Those experts then come up with their own independent estimates. The facilitator then shows the estimates to the whole group, who discuss each of the estimates and the assumptions underpinning them.
That process then repeats one or more times until a consensus is reached, or the facilitator takes an average of the estimates.
This might sound more complicated or obtuse, but is actually similar in some respects to agile poker.
No estimates
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!).
Conclusion
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. Have you tried any other Planning Poker alternatives? How did they go? Let me know in the comments.
If you’re still unsure about Planning Poker and how it works, this video might help you understand it better.
