By Lorna Jane Mitchell

Better Estimates with Planning Poker

By Lorna Jane Mitchell

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, 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.


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

  • Well thanks lorna,
    Very clearly explained, this method make sense to schedule the timeframes in project management. Considering and giving opportunity to everyone and express their views on their estimations can bring out more quality timeframe to schedule the tasks.
    I feel that this can only be applicable, if you have the proper (fixed) specifications of the project or work.

    • An important point to note: this technique allows accurate specification of well-defined tasks *and* can identify those tasks which are unclear. Scope creep can still ruin everything though!

  • shourav

    my barothar like this!pokar!

  • This is a fantastic idea. I will try this out with my team at work.

  • Americo Savinon

    Don’t be scare of doing Planning Poker if you have remote team members, a Google Hangout or Skype Conference should work just fine.

    • This is an excellent point – in fact I’ve previous used an asynchronous adaptation of this technique: send a spreadsheet of tasks to two or more developers asking them to estimate each one, in hours, and add any notes they want to. When you paste all the results side-by-side, you get a good picture of how your estimates look. It’s not as good as the real thing but I’m almost always a remote worker, so it’s an option.

  • As usual, a very good article. I’m going to try this out :)

  • Nick Hoh

    Hi Lorna, nice article. I’m curious how you do the very first session and the very first estimate. Say the team is new and they estimate the 1st story is an 8, but later on they realize that they’ve estimated it too high and looking back they now think that 1st story should be a 3. Do you let the team go back and estimate all the stories again or do you do some kind of anchoring exercise at the beginning where everyone picks a story they agree is a 2 or a 5?

Get the latest in PHP, once a week, for free.