Your Team Disagrees on Every Estimate?

Your Team Disagrees on Every Estimate? Good. Here’s How to Use It Instead of Fighting It

If your team always agrees on estimates, you have a bigger problem than you think.

Constant disagreement in Planning Poker isn’t a sign your team is broken. It’s a sign they’re actually thinking. The real issue is what you do with that disagreement.

Most teams do this:

Flip cards
See wildly different numbers (2, 5, 13, 21…)
Argue until someone gives up
“Compromise” on a number no one really believes
Repeat, sprint after sprint

Then they wonder why their forecasts are garbage and why planning meetings feel like a slow-motion car crash.

There’s a simple Planning Poker technique that turns disagreement from chaos into clarity. And it’s not “let’s just average the numbers.”

Let’s walk through it.

Why Your Team Keeps Disagreeing on Estimates (And Why That’s Not the Problem)

Before fixing the technique, understand why you’re seeing disagreement.

1. You’re Actually Estimating Different Work

When someone says “This is a 3” and someone else says “This is a 13,” they’re almost never estimating the same thing.

They’re estimating:

Different scopes (“Just the API” vs “API + UI + tests + monitoring”)
Different assumptions (“We’ll reuse existing code” vs “We’ll have to build from scratch”)
Different definitions of done (“Code merged” vs “In production with metrics and alerts”)

Disagreement is a signal: your shared understanding is broken, not your estimation skills.

2. People Are Estimating Risk, Not Just Effort

Some devs estimate:

Pure effort: “If everything goes well, this is a 3.” Others estimate:
Effort + risk + unknowns: “Given the legacy code and flaky tests, this is at least an 8.”

Both are valid perspectives. The problem is you’re mixing them without acknowledging it.

3. Power Dynamics Are Warping the Numbers

Whether you like it or not:

Senior devs anchor the team
Loud voices dominate
Juniors sandbag or stay quiet
Product owners subtly push for lower estimates

So you’re not really estimating effort. You’re negotiating expectations.

The Fix: The “Extreme Outlier First” Planning Poker Technique

Most teams run Planning Poker like this:

Discuss the story.
Everyone picks a card.
Flip cards.
Everyone defends their number.
Argue.
Land on something “in the middle.”

This is slow, political, and often wrong.

Here’s a better way: Extreme Outlier First. It’s a simple tweak that completely changes the quality of the conversation.

Step 1: Estimate Quietly and Independently

Use cards or a digital tool.
No “I’m thinking around a 5” chatter.
No hints from senior devs.
No “What did we give the last one?” comparisons.

You want true independent thinking. That’s how you surface real differences.

Step 2: Reveal and Identify the Extremes

When you reveal the estimates:

Ignore the middle.
Find the lowest and highest numbers.
Those people are your key voices for this round.

Example:

Estimates: 3, 5, 5, 8, 13, 21
You don’t ask everyone to explain.
You talk to the 3 and the 21 first.

Step 3: Only the Extremes Explain — Briefly

Ask two questions, in this order:

To the lowest estimate:
“What are you assuming that makes this so small?”
To the highest estimate:
“What are you worried about that makes this so big?”

Key rules:

Keep it short (30–60 seconds each).
No one else jumps in yet.
Focus on assumptions, not defending your number.

This is where the magic happens. You’ll hear:

“I assumed we’re reusing the existing API.”
“I assumed we’re supporting three different clients.”
“I assumed QA is in scope.”
“I assumed we need production monitoring.”

You’re not resolving conflict. You’re revealing hidden assumptions.

Step 4: Clarify Scope and Assumptions as a Team

Now the team steps in — but not to argue numbers.

They clarify:

“Are we supporting three clients or one?”
“Is QA in the story or part of the testing pipeline?”
“Are we including deployment and monitoring?”

The product owner and team lock in what’s actually in scope.
You’re converging on a shared mental model, not a shared number.

Step 5: Re-Estimate Quietly

Once scope and assumptions are clarified:

Everyone re-selects a card.
Again, silently. No anchoring.
Reveal again.

Most of the time, you’ll see the spread narrow dramatically:

Before: 3, 5, 5, 8, 13, 21
After: 5, 5, 8, 8, 8, 13

If it’s still very spread out, repeat:

Ask the new extremes.
Clarify assumptions.
Re-estimate once more.

Limit it to two cycles per story. If it’s still unclear, that tells you something important…

Step 6: Use Disagreement as a Split Signal

If you still have a huge spread after two rounds:

Don’t force agreement.
Don’t waste 20 minutes arguing.

Instead:

Split the story along the lines of disagreement.
- Example: “Spike to investigate legacy API (3)” and “Implement feature using findings (13).”
Estimate the smaller, clearer piece.
Defer the rest until you learn more.

Teams that do this consistently:

Reduce cycle time
Improve predictability
Spend less time in painful planning sessions

A Real-World Example: From 90-Minute Fights to 35-Minute Planning

One team I coached had this pattern:

2-hour planning sessions
10–12 stories
At least 2–3 stories per session turned into heated estimate debates

They introduced Extreme Outlier First with strict rules:

Only extremes talk first
Max 2 rounds per story
If still unclear → split or spike

After 4 sprints:

Average planning time dropped from ~120 minutes to ~35–45 minutes
Percentage of stories completed in the sprint increased from ~60% to ~85%
They stopped treating planning like a punishment

The key wasn’t “better numbers.”
It was better conversations and the willingness to let disagreement drive story splitting.

Common Mistakes That Make Planning Poker Useless

If your Planning Poker sessions feel painful or pointless, you’re probably doing at least one of these.

Mistake #1: Forcing Consensus on Every Story

You don’t need perfect agreement on every estimate.

What you need:

Shared understanding of scope
Agreement that the number is “good enough” to plan around
The ability to revise when you learn more

If you’re burning 10–15 minutes on a single estimate, you’re not being “thorough.” You’re wasting time.

Mistake #2: Letting Seniors or Architects Go First

If the most senior person explains their number (or even shows it) first:

Everyone else orbits around that number.
Juniors assume they missed something.
You lose the value of diverse perspectives.

That’s anchoring bias in action.

Mistake #3: Treating Estimates as Commitments

If your organization uses estimates to:

Judge individual performance
Beat teams up for “missing” story points
Compare teams against each other

Then of course people will:

Inflate estimates defensively
Sandbag
Avoid taking on unknown work

Story points are for forecasting and planning, not for accountability theater.

Mistake #4: “Discuss Until We Agree” Without Structure

Unstructured debate sounds like:

“I just feel like it’s a 5.”
“But last time we did something similar, it was a 3.”
“Yeah, but that one had fewer edge cases.”
“I still think 8 is too high.”

You’re not clarifying anything. You’re just trading opinions.

Extreme Outlier First gives you a structure:

Focus on assumptions
Focus on extremes
Time-box the conversation

Mistake #5: Estimating Work That’s Obviously Too Big

If everyone throws 21 or “?”:

Stop.
Don’t argue.
Don’t try to “pick a number anyway.”

The correct move is:

“This is clearly not ready.”
“We need to split this or spike it.”
“Let’s not pretend we know more than we do.”

Practical Tips to Make This Technique Work in Your Team

Here’s how to put Extreme Outlier First into practice without turning it into yet another “process thing” everyone hates.

1. Add Three Simple Rules to Your Planning Poker

Announce these before your next session:

No pre-discussion of numbers.
Everyone picks privately.
Only extremes explain first.
Lowest and highest get 30–60 seconds each.
Max two rounds per story.
If still unclear, we split or spike.

Write these on a whiteboard or in your meeting notes so you can point to them when the discussion drifts.

2. Change the Question You’re Asking

Instead of:

“What number do you think this is?”

Ask:

“Given our definition of done and assumptions, how big is this relative to our other stories?”

And during discussion, ask:

“What assumption is driving your estimate?”
“What’s the riskiest part of this story?”
“What would make this not fit in a sprint?”

This shifts the conversation from defending numbers to exposing assumptions.

3. Use Concrete Reference Stories

If your team constantly argues about whether something is a 3 or a 5, you probably lack reference points.

Pick a few real stories from your past sprints:

“This login screen story is our 3.”
“This multi-step workflow refactor is our 8.”
“This cross-service integration is our 13.”

Then compare:

“Is this closer to the login screen (3) or the refactor (8)?”

Relative estimation works best with real anchors, not abstract Fibonacci numbers.

4. Time-Box Story Discussion Ruthlessly

Set a visible timer:

3–5 minutes per story, max
2 estimation rounds per story, max

If you hit the limit:

Decide: “Split, spike, or accept rough estimate.”
Move on.

Planning is about good enough decisions, not perfect certainty.

5. Make Story Splitting a First-Class Outcome

Teach your team that:

“We couldn’t agree, so we split it” is a success, not a failure.
Big, vague stories turning into smaller, clearer ones is exactly what you want.

When in doubt, ask:

“What’s the smallest slice that still delivers value or learning?”
“Can we spike the unknown part and estimate the rest later?”

6. Protect Psychological Safety Around Estimates

If people feel judged for “wrong” estimates:

They’ll stop being honest.
They’ll align with the loudest person.
Your estimates will get more consistent and more useless.

Do:

Normalize being wrong: “We learned something, let’s update our assumptions.”
Review variance at the team level, not per person.
Use retro time to refine your approach when estimates are consistently off.

Don’t:

Call out individuals for “bad estimates.”
Use points to compare devs or teams.
Treat points as a productivity metric.

Tools That Make This Easier (Without Becoming the Point)

You don’t need a heavyweight tool to run Extreme Outlier First, but a simple digital Planning Poker setup helps, especially for remote or hybrid teams.

Look for:

Anonymous voting to reduce anchoring and status bias
Fast, no-signup sessions so you’re not wasting time on setup
Integration with your backlog tool (like Jira) so estimates actually stick

A lightweight example is ScrumPoi, which supports planning poker and retrospectives with anonymous voting, free team usage, and Jira integration. Use something like that to enforce the “everyone votes independently” rule without turning the session into a tooling exercise.

Stop Fixating on the Number. Fix the Conversation.

If your team disagrees on every estimate, your problem isn’t Planning Poker.
Your problem is how you’re using it.

Disagreement is not a bug; it’s a diagnostic.
The extremes are where the learning lives.
The goal isn’t consensus — it’s clarity.

Adopt Extreme Outlier First:

Lowest and highest talk first
Focus on assumptions
Time-box the debate
Split or spike when you’re still far apart

You’ll spend less time arguing, ship more predictable work, and finally turn estimation from a ritual everyone dreads into a tool your team actually respects.

Your Team Disagrees on Every Estimate? This Planning Poker Technique Fixes It