Stop Playing Planning Poker: Why Relative Estimation Wins Every Time

Why do your team’s estimates always feel wrong? 

We’ve all been there: sticky notes flying, decks of Planning Poker® cards at the ready, yet by Sprint’s end… your team is scrambling, or worse, carrying over unfinished work.

Sound familiar?

Here’s the uncomfortable truth: It’s not because your team isn’t smart. It’s because time-based estimates and traditional methods like Planning Poker® set you up to fail from the start.

There’s a better way. One that gets your team out of their heads avoids the usual estimation traps, and focuses on what really matters—shared understanding and sustainable delivery.

I’m talking about Relative Estimation.

Let’s Start with a Quick Thought Exercise 🧠

Imagine you’ve got a cluttered garage (or storage unit, attic, insert your personal chaos zone here).

Now, try estimating how much effort it will take to clean it up—using Story Points only.

Done?

Here’s the catch: Be honest. Did your brain immediately start converting effort into hours, then back into Story Points?

If you said “Yes,” you’re not alone. Most people default straight to time. I’ve taught hundreds of teams, and that’s almost always where the mind goes first. It’s deeply wired into how we think about work.

Why Time-Based Estimates Will Trip You Up Every Time

There’s a mountain of research on this, so let’s hit the highlights:

1. Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” In other words, even when you think you’re padding your estimate, you’re probably underestimating. 
2. Optimism Bias: We all like to believe we’re the exception to the rule. “This time, it’ll go smoother. We’ve learned!” Sure… until reality sets in. 
3. The Planning Fallacy: A nasty combination of the above plus a tendency to forget past struggles. “It took us a month last time, but surely we can knock it out in two weeks now.” 
4. We’re Terrible at Estimating Anything Over Four Hours: Three decades in project work, and I’ve consistently seen people struggle with anything longer than half a day. Want to know how long it’ll take to clean your desk? No problem. Want to know how long it’ll take to rebuild your infrastructure? Good luck. 

The last time we moved, my wife asked me how long I thought it would take to pack up and clean the garage. We’d been living in the house for fifteen years, and we had a lot of hobbies and memories in that garage. Still, I shrugged and said, “A couple of days.” 

A week later and two complete flatbed garbage containers later, I wasn’t done. 

The Common Fix Teams Use (That Doesn’t Actually Fix Much)

So, what’s the solution most teams turn to?

Enter Planning Poker®—the popular go-to estimation tool in the Agile world for nearly two decades.

It sounds like the answer:

• It replaces hours with abstract points.
• Everyone gets a voice.
• It feels collaborative.

The problem is, while Planning Poker may look like it solves time-based traps, it carries hidden flaws of its own—ones that quietly trip up teams sprint after sprint.

Now, don’t get me wrong—there’s a reason teams love Planning Poker.

It’s structured, familiar, and feels democratic. Everyone holds a card. Everyone plays.

The problem? Underneath that sense of fairness, bias, isolation, and context gaps creep in.

Let’s look closer.

Why Planning Poker Falls Short ♠️♥️

A quick refresher:

• The team gets Fibonacci cards (1,2,3,5,8, and so on).
• One item at a time, everyone picks their estimate.
• Reveal cards.
• Debate.
• Repeat.

Simple. Familiar. Sounds collaborative. It even uses the facilitative decision-making technique of simultaneous reveal. 

Only… it’s not as effective as we think.

Here’s why:

1. It’s All In Your Head

Everyone starts by thinking their way through the work. And guess what? The easiest person to agree with is… yourself.

Worse, they’re thinking about how they would do it, not how the team will do it.

2. No Context, One Item at a Time

Planning Poker isolates each item as if it exists in a vacuum. The problem? Real work is messy, interconnected, and relative—context matters.

3. Bias Creeps In Fast

Authority bias. Groupthink. The “expert effect.”
We’ve all seen it:

• The senior dev says, “3.”
• The junior dev says, “13.”
• After one explanation from the senior dev, everyone shifts down to “3.”

The reality? That estimate now reflects the expert’s ability, not the team’s.

Back when I worked at AOL, I supported a team made up entirely of early-career developers. The newest member had graduated college just the year before; the most experienced had three years under their belt. Because of this, their manager felt the need to stay deeply involved—even though they weren’t contributing directly to the development work.

During estimation sessions, I noticed a troubling pattern. The team would give their initial estimates, only for the manager to step in and push them to lower the numbers based on their own assessment of complexity. The catch? The manager wasn’t doing any of the work.

On a hunch, I started recording the team’s original estimates before the manager’s input.

Sure enough, when the project wrapped up, the actual effort aligned much more closely to the team’s original estimates—not the ones adjusted under pressure. Which, of course, left the team appearing behind schedule.

Relative Estimation: How to Stop Debating and Start Delivering 🚀

What makes Relative Estimation better?

Two things:

1. It’s About Relationships, Not Absolutes

Instead of evaluating each item in isolation, the team compares items side by side:

“Is this story more effort, less effort, or about the same as the last one?”

Think of it like this:

You’re at the holiday potluck, standing in the buffet line, and you reach the tray of lemon-sautéed chicken breasts. Do you pull out a food scale and weigh three different pieces to find the one that’s exactly five ounces? Of course not. You compare a few pieces and choose the one that looks right to you.

2. It’s Collaborative, Not Competitive

In Team Estimation, the conversation flows naturally. The team shares understanding out loud, not in silos. Debate happens, yes, and it’s framed by comparison rather than isolated opinion.

Quick Start: How to Use Relative Estimation Effectively

Here’s the simple flow:

1. Take one item of work and put it on your “table.” Ensure everyone understands it. 
2. Take a second item and put it just below the first item.
3. Start comparing: Bigger? Smaller? About the same?
4. Continue until all items are relatively sized.
5. (Optional) Apply a Story Point scale after all comparisons are done.

The result? Teams get better at understanding complexity together. Estimates become useful, not arbitrary.

Still Using Planning Poker? Try This Instead.

Relative Estimation won’t magically make estimation perfect. Nothing will.

What it does do is shift the focus where it belongs:

• Shared understanding
• Context
• Collaboration
• Comparison over isolation

Want to avoid endless debates and tap into your team’s collective smarts? Try it. If you’re like me, you’ll never go back.