Better Estimates with Planning Poker

Planning Poker is an estimation technique which helps developers provide good estimates for project tasks. It comes from the world of Agile software development, but can be used in isolation or with other methodologies as well.

When you use Planning Poker to estimate your project, it is very important to give each developer a voice; allow them to make their own estimates without being influenced by the opinions or agendas of anyone else. When this is the case, Planning Poker enables you to do two very valuable things:

• You can look at the various estimates for the same task and gain a clear sense of how long this task will take. Since developers tend to under- or over-estimate, you may need to adjust this number.
• It becomes possible to spot tasks where the developers’ estimates differ wildly from one another. When this happens it means the task is not well defined. The unknown elements cause different developers to make different assumptions; the task needs to be amended until everyone is able to estimate.

In this article I’ll show you how using Planning Poker with a team can help you make better estimates for the projects you work on.

How to Play Planning Poker

First of all you will need:

• some players (two minimum, three is awesome, and it works with up to five or so)
• a chairperson or facilitator
• some Planning Poker cards
• a list of tasks you want to estimates for

You can purchase special Planning Poker cards (I have a rather nice set from moo.com), make them from index cards, or improvise with an iPhone or Android card app.

The exact selection may differ, but typically you’ll have cards with the values 1/2, 1, 2, 3, 5, 8, 20, and a question mark or unknown value. These are measurements for a task in story points (story points are an imaginary unit, where the simplest task is half a story point, and the bigger the task the more points it is worth). Each person is dealt one of each value. Different teams play with different variations, for example it is fine to treat them as hours spent coding to get started.

The facilitator describes the task to be estimated and everyone selects, but does not show, the card that represents their chosen estimate. On a given signal, everyone reveals their card at the same time. If the numbers are all the same or similar, then accept that (or average them) as the estimate and move on to the next task.

If the numbers differ wildly, then something is amiss with the task or people have made different assumptions about it. For example, one person might think that to show a list of products she would also need to include the search and sort features for the list page; someone else might not have factored that in to his estimate. When this happens, the high estimator and the low estimator are asked to justify their estimates. It is very important that even if it’s the most junior member of the team who made the non-matching estimate that he should have his soapbox to justify things. The point of the exercise is to give everyone a voice, so pulling rank is not allowed! Figure out if the task or user story needs to be broken down or a better description, or if one of the players has misunderstood something. Re-estimate if you need to, and then move on.

The process is repeated, with the agreed estimate numbers being recorded by the facilitator, until all the tasks have been estimated.

It’s often the case that tasks get more difficult to estimate as they get larger, and there should certainly be an upper limit for estimates. Personally, I recommend anything more than a day long is too big and should be split into smaller tasks. This approach fits in well with the daily stand-up style meetings where everyone is asked what they’ve done and what they’ll be working on next.

Tips for Successful Planning Poker

Be militant about not allowing any discussion except over a specific estimate mismatch. And even then, don’t let people get sidetracked. It is very important to keep the meeting from dragging on. Some things can’t be estimated for; if you talk about any one point for more than three minutes, forget it and move on. It is not a spec-writing exercise; that should have been done already. That feature will have to be better described or more investigation needed before an estimate can be made and you don’t want to waste meeting time (you have at least four members of your team in the room and that’s a lot of resource to be burning!) when one person could sort it out later.

Either limit the meeting time to an agreed length, or run a humane format. It’s common to let the meeting run for 50 minutes, then break for 10 so people can visit the bathroom, get a drink, take a phone call or whatever they need to do. You can then restart and run the meeting for another 50 minutes, and so on, until it is done. If it’s lunchtime, make sure you either have a longer break or order in food. For a 2-week sprint, the meeting should not run for more than 2-3 hours as a rule of thumb.

Summary

Planning Poker is just one tool in the box but I find that using it enables getting the best out of the “hive mind” within a limited timescale. Once you have decent estimates, you can plan your project more accurately.

Don’t be alarmed if the estimations are significantly bigger than you would usually expect from a project of similar size! My experience is that the overrun is much smaller when you use a detailed, distributed estimation approach like Planning Poker, so your project will deliver in approximately the same time as normal but you’ll have a much clearer idea of what that timescale is.

If you already use this technique, or have adopted it now after you’ve read this article, I’d be interested to hear what you think of it and whether you changed the process above in any way. Leave a comment, please :)

Image via Charles Taylor / Shutterstock