← Back to blog

Get Better Results from Your Planning Poker Estimation

The planning poker estimation technique is a strategy teams use to estimate the work of agile stories taken from group feedback.
October 28, 2022 • Keshav Malik

If you’ve been anywhere near the software industry in the last decade, we know you’ve heard the word Agile. After all, many teams hopped on the Agile bandwagon, producing software to completion in short cycles. But planning a sprint isn’t that simple. The industry average for planning accuracy in a sprint is below 50%, meaning your teams aren’t planning out their sprints properly most of the time. So how do we fix this? Many teams have turned to a unique method called the Planning Poker Estimation technique.

But is this technique really your best option for estimating projects? We don’t think so. 

Table of Contents

What Is Planning Poker?

The planning poker estimation technique—aka scrum poker—is a gamified strategy that agile teams use to approximate the work of agile stories. Planning poker was first outlined and defined by James Grenning in 2002, but it would later be popularized in Agile Estimating and Planning by Mike Cohn, whose company trademarked the term. 

Originally, planning poker was created to speed up the planning process, as the original Wideband Delphi method was too time-consuming. Instead, teams use playing cards to weigh in on the effort it would take for a particular user story. These estimations come from the entire group's feedback and agreement, making the estimation activity seriously captivating. Wanna play?

Pull quote saying "the planning poker estimation technique is a gamified strategy that agile teams use to approximate the work of agile stories".
Shall we place some bets?

(Did you know that regular poker can also benefit software developers? Our COO, Dan Lines, sat down with Jeff Meyerson, and they discussed how playing poker can actually help you succeed in software development!)

How Planning Poker Estimation Technique Works

Let's break the technique into two different parts to understand it easily.

1. Initial Stage

Before a poker-arranging meeting, the product owner or client either brings up a new feature, covers customer feedback, or does anything else that might warrant development time.

Then, each participant is handed a deck of cards, generally numbered 1-21 or in a Fibonacci sequence. These numbers can address a few things: how many story points they think it needs, how many days it might take, or any other metric that the team might use.

The planning poker cards are intentionally designed to start small and increment quickly, so participants are encouraged to come to an agreement. Assuming they have a card for each number from one to 50, the cycle would be agonizing.

The mediator (the product owner or scrum master) explains the case to the group. Members are free to ask more questions if they need more information. Once everyone’s heard the story, everyone shares their perspectives on it. 

Remote teams can run these meetings asynchronously by giving each estimator stories to weigh in on individually. This allows them each to take as much time as they need to fully flesh out their reasoning, and the mediator can use that to finalize a result.

Image of the painting "dogs playing poker".
Do you think these pups reached a consensus yet?

2. After-Discussion Stage

After the discussion, each person will privately choose a card from the deck. Generally, the card will show an estimate of story points, but it can also represent the number of ideal days. Once everyone selects a card, everyone reveals their estimate.

If the universe is kind to you, team members show the same card. And this number turns into an accord. And you can then merrily move on to the next story.

But chances are, that won’t happen. Estimates fluctuate—like, a lot. So, the team will continue to have more dialogues on the story. People who choose higher or lower numbers will have to explain their points of view. They may even attempt to persuade others to follow suit.

Naturally, after several (sometimes frustrating) rounds, the numbers should start to look more uniform. And once everyone agrees on one number, the game is over. The number will be the estimated time or duration for the project. You can go ahead and pop the confetti now! 

Does this feel reminiscent of your family game night? Yeah, it is. And just like your game nights with your dysfunctional bunch, you’re likely going to run into some problems with the planning poker estimation technique. 

We know that planning accuracy is hard. Learn more about our six-step recipe for improvement.

The Purpose of Planning Poker

When Planning Poker first came into use, it was primarily designed to replace the existing method, called Wideband Delphi. That method was incredibly time-consuming and required the estimators to fill out forms to explain their reasoning behind their estimates. 

With Planning Poker, your team of estimators should be able to discuss each user story and get accurate estimates based on the number of story points you agreed upon. Since it’s intentionally a gamified technique, you challenge your development teams to be honest and accurate in setting goals in a sprint.

Planning accuracy is directly improved by using methods like this, and that can make a huge difference. In fact, these benchmarks allow you to create more detailed and accurate reports and truly show what your teams are working on. And you can improve more than just that metric, especially when you start measuring other engineering metrics.

Planning Poker Alternatives

If poker isn’t your game, your teams can still use other gamified techniques for sprint planning. Here are some other common alternatives:

  • Bucket System: This game is similar to poker, but instead of passing around cards, you use buckets (or whatever equivalent you can find). Estimators discuss the number of story points required for the item and place it in a corresponding bucket. It’s a faster equivalent to planning poker but doesn’t allow for as many in-depth discussions.
  • T-Shirt Sizing: This game involves—you guessed it—T-shirts, starting with extra small sizes and going up to XL. Basically, you assign items to these sizes to determine how difficult or tedious a task might be. This works much better for dealing with backlogged items but doesn’t provide you with any hard data or a concrete number of story points.
  • Dot Voting: This method lets development teams cast votes using small stickers. You first lay out your assortment of issues, and your team places stickers to determine how important an item might be. The more stickers, the more work a task needs. But this game doesn’t give you any information about story points, it only shows you what's most important for teams. 

No matter which solution you end up using, you must remember that it won’t be a perfect method. These gamification techniques provide you with a loose estimation of your planning accuracy, but without hard data, that’s all it is—just an estimate.

The Limits of Estimation Techniques

At the end of the day, these are all great techniques to estimate your workloads, but what does that accomplish? You need hard data to show what your teams are getting done, and these games don’t provide that. 

The key to measuring planning efficiency is to get actual insights and data into how your team is performing, and how accurate their plans are. Without the insights, things will quickly go downhill. The planning estimations—which were great at first—end poorly, and cause delays you could’ve avoided. 

And once these delays start, they can ripple through the entire organization. A missed deadline can make a potential marketing campaign miss its mark, clients miss out on promised new features, and execs can’t commit to revenue targets. And now, instead of playing estimation poker, everyone’s playing a sad game of dominoes. 

Plus, none of these techniques can account for added work or unplanned additions during a sprint. Mike Gordon from Hippo gives us some great advice on this:

“...if you’re going to have ten story points, plan for seven of them and leave three of them unplanned. Because those three unplanned will always happen.”

Mike gordon of hippo
Want to learn more about improving software development productivity? Check out how our customer Hippo Insurance increased their productivity.

Get More from Your Planning Poker Estimation Technique

Measuring your team’s planning accuracy is crucial to making sure your team can commit and hit their goals as needed. Even if you can get a good estimation down, that’s only part of the overall problem. And if you want to really take advantage of proper planning accuracy, LinearB’s Project Delivery Tracker has it all baked right in for you.

Taking factors like unplanned work, backlogged items, and the overall release velocity of your teams can paint a much better picture of how often your teams are hitting their marks. The formula is simple: Better Planning Accuracy = Improved Delivery = More business value. 

Planning accuracy over time
Using LinearB's Project Delivery Tracker can help you visualize unplanned work your team is doing each sprint and improve your planning accuracy. Book a demo today!

Further Reading

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering and product leaders striving to be better for their teams.

LinearB may send you email occasionally about how you can optimize productivity.
We will not share your information with anyone. Ever.