"Planning Poker" in Agile Project Management

A Fun and Useful Tool for Estimating

© iStockphoto

Planning Poker is a safe bet for boosting your Agile project development.

Imagine that you're working out the budget for a large, complex and fast-moving project.

You spend hours talking to the different people involved, researching best- and worst-case scenarios, and calculating costs, even though much of the project is beyond your control and expertise.

It takes you a week to finalize your schedule and finance. But no sooner have you done so than you discover that the project requirements have changed, and much of your work is now irrelevant. What a waste of time, energy and resources! Surely there's a better way?

In this article, we look at how playing "planning poker" can help you to estimate what's required for your project in a fun, fast and effective way. And, as part of the Agile approach to project management, it involves all of your team members in the process.

What Is Agile Project Management?

Agile Project Management is an iterative, flexible approach to project planning. The technique works well in fast-paced environments, in complex situations, and when requirements frequently change, such as in software development.

Agile gives teams the freedom to adapt the way that they work, which means that the final product is often different from the original idea. But, because the customer is involved throughout, and because team members learn from each iteration, they are able to deliver a product that the end user actually wants.

Agile project teams aim to deliver working elements regularly throughout the project, rather than to deliver a single, final result at the project's end. To do this, they work in short bursts called "sprints." Each sprint starts with a planning meeting, when team members discuss what they can deliver, agree objectives, and divide tasks between them.

During a sprint, the team meets every day at a short "scrum" meeting. Members talk about what they're working on, alert one another to any issues, and discuss possible solutions. Then, at the end of the sprint, the team collaborates with the customer to make sure that he or she is satisfied with the product and the work done so far.

An effective way of dividing project work among team members is to break it into smaller elements known as "user stories". These are made up of:

  1. A written description of the desired outcome from the user's point of view.
  2. A team discussion to flesh out the finer detail.
  3. A test at the end of the sprint to check that the customer is satisfied with what's been produced.

"Planning Poker" in Agile Project Management

The responsibility for estimating the time and costs of a product traditionally often falls to an individual, and can take a lot of time and effort. But, as Agile expert Mike Cohn points out in his 2005 book, Agile Estimating and Planning, using more time and energy does not necessarily increase accuracy. The diagram below shows the relationship between these two elements:

Figure 1 – Planning Poker in Agile Project Management

Planning Poker in Agile Project Management

Cohn, Mike, Agile Estimating and Planning, 1st Ed., ©2006. Reproduced by permission of Pearson Education, Inc., New York, New York.

This diagram demonstrates that you only need to put in a little effort to increase the accuracy of your estimates dramatically. It also highlights that it's possible to put in too much time, and achieve a less accurate result.

Cohn suggests Agile teams play "planning poker" in their scrum meetings to estimate the costs and timings of user stories. (This isn't actually poker, but does use playing cards or home-made scorecards.)

The idea originated in the 1950s from an approach to forecasting called the Delphi method. This later became known as the Wideband Delphi technique. "Planning poker" was developed by Agile consultant James Grenning in 2002, and popularized by Cohn three years later. Grenning refined his version in 2009 with his "Planning Poker Party."

According to Cohn, playing "planning poker" is a quick and effective way to engage your team to help to plan and estimate aspects of your Agile project. He says that you improve the accuracy of your planning because you use:

  1. Expert opinion (your team's).
  2. Analogy (comparing one piece of work with another).
  3. Disaggregation (splitting a project into smaller parts to make estimating more simple).

And you don't rely on just one person's judgment. Cohn says that it's beneficial to involve everyone from the outset, as it isn't always clear who will do what during a sprint.


A principle of Agile project management is that estimating inevitably involves guessing. Planning poker is a tool to help you to guess better.

Planning Poker: A Step-by-Step Guide

Step 1: Preparation

Before you get started, there are a few things to consider:

  • When to Play: play planning poker when there are a number of items to estimate at the beginning of a project, or when team members identify new user stories at the start of a sprint.
  • Time Needed: this depends on how many user stories you have to estimate, and the size of your team. As a rough guide, you might need one to three hours per session.
  • Who to Include: everyone in the Agile team, including developers, testers, analysts, and engineers. If you have 10 people or more in your Agile team, split them into two groups. The product owner is typically the moderator.

Finding This Article Useful?

You can learn another 64 project management skills, like this, by joining the Mind Tools Club.

Join the Mind Tools Club Today!

Next, prepare a deck of estimation cards for each participant. These should be large enough for each team member to see across a table.

Mark each deck with the following numbers: 1, 2, 3, 5, 8, 13, 20, 40, and 100. These are "story points." The more costly, complex and time consuming a "player" believes the story to be, the more story points he will assign to it. (Use non-consecutive numbers, so that you don't try to estimate too precisely. This range also reflects the greater uncertainty of trying to estimate larger items.)

If you prefer, you could use a simpler scoring system, for example making cards with sizing codes such as S, M, L, XL, XXL. You can add a card to indicate that the user story is simply too big to score and needs to be broken down into smaller stories (an infinity symbol) and another to show that more information is needed before a score is possible (a question mark).


Don't confuse story points with units of time. Each member of the project team will likely work at different speeds, so will be thinking of a different number of hours or days to complete a task. However, they can agree on the scale of the work.

Step 2: Instructions for the Moderator

  1. Sit your team around a table and give each member a deck of planning poker cards.
  2. Remind everyone of the effort/accuracy curve (see the diagram above). Tell them that the goal is to keep to the left of the effort line, where they can arrive at a valuable estimate easily.
  3. Read the description for each user story, and ask your team to discuss it. Make sure that you prepare thoroughly beforehand, so that you are able to answer any questions.


Don't let the discussion take too long or you risk expending too much effort. Consider using a timer to encourage people to estimate rapidly.

  1. Next, ask participants to select a card in private to represent their estimates of the size of each user story. They need to take time, complexity and risk into consideration, and to include all types of task, such as analysis, development, testing, and documentation. Once they've finished, ask them to turn their cards over simultaneously and show them to one another.
  2. Where estimates differ (and they're likely to), encourage the people with the highest and lowest scores to explain and discuss their decisions. Make notes if you think that any of these points might be useful when you're at the programming or testing stages.
  3. Get participants to re-estimate and reveal their cards at the same time again. The goal is for everyone to converge on a single number. This often happens by the second round. If not, repeat the cycle again. (It rarely takes more than three rounds.)


It's OK if one person doesn't have the exact same estimate as everyone else after a couple of rounds, or if there's a tie between two consecutive sizes. If this happens, pick the larger size and move on. The point of the exercise is to achieve reasonableness, not perfection!

Step 3: What's Next?

After playing planning poker, the team will understand the scale and complexity of its user stories. These batches of work can now be prioritized and scheduled (roughly) into a plan for the next sprint. The people who will be doing the work will now be assigning themselves the tasks, so they are in the perfect position to know how long something will take – though they'll still be guessing!

Key Points

Agile is an iterative, flexible approach to project planning. Teams work in "sprints" and meet for daily "scrum" meetings, to report on their progress toward completing pieces of work known as "user stories."

Agile expert Mike Cohn suggests Agile teams play "planning poker" to estimate the scale of the effort involved in a project. The "players" are given a deck of cards marked with "story points."

After discussing a user story, each player picks a card that she thinks represents the scale of the project – a low number if it is straightforward, or a higher number if it is more complex. The players then discuss their estimates, and use the cards again, with the aim of achieving consensus.

Once everyone agrees on the project's scale, the work can be scheduled and planned.