Planning poker: The all-in strategy for Agile estimation

Imagine you bought a house and you’re planning to remodel the kitchen. You ask a contractor for an estimate on how long the remodel will take and approximately how much it will cost. They give you an estimate, but two months later, you’re regretting your decision because the project is far past the original timeline and well over budget. 

When you have just one person’s opinion, you only have their input and expertise to consider. However, when you get more people with varying experience into the mix, you get a more well-rounded and accurate estimate of what work needs to be done.

This consensus-based estimation is the basis of the Agile planning poker method. 

What is planning poker?

Planning poker is an estimation method that helps your Agile team project the amount of effort one user story in a product backlog could take to complete. Often used in Agile project management methodologies, it’s sometimes referred to as “Scrum poker” or “pointing poker.” The “poker” aspect of the name refers to the cards that each team member uses during the process.

The history of planning poker

Planning poker is based on a technique known as Wideband Delphi. Wideband Delphi is a consensus-based estimation process developed in the mid-20th century by the RAND Corporation, a nonprofit think tank. 

James Grenning, an author of “The Manifesto for Agile Software Development,” refined the Wideband Delphi technique in 2002 and renamed it to Planning Poker. It was then refined even further and popularized by Mike Cohn in his 2005 book, “Agile Estimating and Planning.” 

How planning poker works

The planning poker process happens early on in the sprint planning process, so Scrum masters and product managers can get an accurate sense of how much work can be completed in each sprint. Here’s how it works:

1. Create planning poker cards

Everyone on your Scrum team or Agile team has a deck of cards with different values on them. Each card will have one of these values: 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. These numbers may seem random, but they’re actually rounded variations of the Fibonacci sequence. These values most commonly represent story points. However, some teams may use them as a time-based estimation for how long a user story may take to complete. The most common time-based estimation is measured in hours.

The product owner or the Scrum master will act as a moderator and read a specific user story from the product or sprint backlog. Team members then have the opportunity to ask questions and clarify as needed so the entire team can get an accurate sense of what work needs to be completed for that specific backlog item. 

Here are a few questions your team can ask to better understand a user story:

• What are some different techniques we can use to complete that story?

• How many people will need to work on this story?

• How will stakeholders respond if there are any delays to this story?

2. Vote on each user story

Once your team finishes the discussion of one user story, then each estimator chooses a card that corresponds to the amount of effort or story points they think correlate to that backlog item. Everyone then reveals their card at the same time. If everyone chooses the same estimate, that becomes the official estimate for that backlog item. The goal is for everyone to have the same estimation. 

3. Come to a consensus

If team members have differing opinions about their initial estimates, the team member with the highest estimate and the team member with the lowest estimate take some time to discuss why they chose that specific number. After this discussion is complete, everyone reselects their cards. This process repeats until the team arrives at a consensus. 

4. Plan your sprint

Now that all of the items in your backlog have estimations, it’s much easier to accurately plan a sprint. Since your entire team has a consensus on how long each task will take, it’s much more likely that you’ll be able to fit the right amount of work into your sprints.

When to have a planning poker session

Planning poker typically occurs right before the sprint planning process, so the product manager or Scrum master can get an accurate sense of work before scheduling out a sprint. You can use this estimation method once per sprint—since items are continually added to a product or sprint backlog, you should have a constant supply of backlog items to pull into each sprint. 

If you only have a small amount of user stories to discuss in your product backlog, you can combine this session onto the end of a daily standup meeting since all team members are already present. 

The benefits of planning poker

The main benefit of planning poker is that your team estimates are more accurate. Having an accurate estimate is an important part of the sprint planning process, because it gives both your team and stakeholders a realistic timeline for when a task will be completed.

Here are a few more ways planning poker can benefit your Agile team:

• Each team member has a say. Everyone on your development team is important and this process gives them an opportunity to make their contribution known. This can help team members stay more engaged with their work. 

• Team members have the opportunity to talk through user stories. During the planning poker process, the development team has an opportunity to work together to talk through user stories before any work actually begins. This helps people get on the same page about how to resolve certain user stories, no matter the developer assigned to that story. 

• Task estimates are relative to other tasks. When your team uses story points to represent the number on their planning poker card, then it’s easier to understand the amount of effort a specific task will take based on other tasks in the pipeline. For example, a user story with a planning poker estimate of 2 will be far easier to complete than a user story with an estimate of 40.

Plan your sprint with a work management tool

Keep your Agile team on the same page by using a work management tool. Asana helps you plan and organize your Agile projects in a tool that’s flexible and collaborative. Whether your team works in a Kanban board or a more linear timeline, Asana has the features to help your Agile team build quickly.