How to Eliminate Anchoring Bias During Agile Estimation

“Your estimates are wrong the moment the first person speaks.”

If that line makes you uncomfortable, good. It should.

Anchoring bias quietly wrecks agile estimation sessions every day. One confident engineer says “Eh, that’s like a 3,” and suddenly the whole team’s range of thinking collapses to 2–5. You call it “consensus.” It’s not. It’s conformity.

Studies show that even random numbers can anchor people’s judgments. In one famous experiment, spinning a rigged roulette wheel changed how people estimated the percentage of African countries in the UN. If a random wheel can skew experts, imagine what your senior architect’s estimate is doing to your team.

If you’re serious about reliable estimates, you have to treat anchoring bias as a first-class problem, not just background noise.

Let’s fix it properly.

What Anchoring Bias Really Looks Like in Agile Estimation

Anchoring isn’t just “someone said a number first.” It’s deeper and more subtle.

The Real-World Symptoms You’re Probably Ignoring

If these feel familiar, you have an anchoring problem:

The same few voices always speak first in estimation
Once someone suggests “8 points,” nobody seriously proposes “2” or “20”
Junior devs rarely disagree with seniors’ estimates
Estimates barely change across refinement sessions, even when the scope clearly grows
During planning poker, people flip cards that are “close” to what the loudest person hinted at

Anchoring bias shows up as:

Narrow ranges: Everything is a 3, 5, or 8; almost nothing is a 1 or 13
Sticky numbers: A number mentioned early keeps resurfacing (“didn’t we say this was about a 5 last time?”)
Deference to authority: “If Alex thinks it’s a 3, I’m probably overthinking it”

Why Anchoring Is So Dangerous for Agile Teams

Anchoring bias doesn’t just hurt “accuracy.” It damages how your team thinks:

Shuts down real discussion: People rationalize toward the anchor instead of exploring uncertainty
Masks knowledge gaps: Quiet disagreement never surfaces, so hidden complexity bites you later
Reinforces hierarchy: Seniors become “the estimators,” juniors become card-flippers

And then you wonder why your forecasts are consistently off by 30–50%.

The Conventional Wisdom Is Wrong (And Too Weak)

Let’s challenge a few common “solutions” you’ve probably heard.

“We Use Planning Poker, So We’re Fine”

No, you’re not.

Planning poker can help, but most teams run it in a way that still encourages anchoring:

People reveal cards one by one instead of simultaneously
Someone casually says, “This feels like an 8 to me” while still “thinking”
The product owner hints: “We really need this soon” (translation: “please don’t estimate this high”)

Planning poker is not magic. If you don’t enforce anonymity and simultaneity, you’re just doing public estimation with cards.

“We Just Let the Experts Estimate”

This is anchoring as a process.

Relying on “the expert”:

Narrows the range of thinking to one person’s mental model
Trains the rest of the team to disengage
Makes estimates heavily dependent on who’s in the room

Experts are useful for insight, not for final numbers. You want their perspective in the discussion, not their number as the anchor.

“We Don’t Estimate, We Just Do Kanban”

Skipping estimates doesn’t eliminate anchoring; it just moves it:

Stakeholders still anchor on “last time something like this took 3 days”
Devs still anchor on “we usually get 5 tickets done per week”
“Quick fix” becomes the deadliest anchor in the building

If you’re going to estimate at all—time, complexity, risk—you need to deal with anchoring explicitly.

What Not to Do: Common Mistakes That Make Anchoring Worse

If you recognize your team in this list, you’re feeding the bias.

Mistake 1: Letting People Talk Before They Vote

This is the biggest one.

When someone starts with:

“This seems small”
“It’s basically the same as ticket ABC-123”
“I’d say it’s around a 3 or 5”

…you’ve already anchored the room before any numbers are shown.

Rule: No opinions, no hints, no “gut feel” comments before everyone has silently chosen a value.

Mistake 2: Revealing Estimates Sequentially

If you go around the room—“Alice, what do you think? Bob? Charlie?”—you’re literally staging anchors in order.

People adjust based on what’s been said. Even if they disagree, they tend to move closer.

Fix: Reveal estimates simultaneously and anonymously.

Mistake 3: Letting Hierarchy Drive the Conversation

Anchoring loves power structures:

The lead engineer speaks first
The architect “corrects” estimates
The product owner “nudges” toward smaller numbers

If senior people always go first, you’re not estimating—you’re rubber-stamping.

Mistake 4: Treating Outliers as “Wrong”

When someone throws a 13 while others are at 3 and 5, many teams react like this:

“Okay, who put 13? Explain yourself.”

That framing assumes the majority is right. Often, the opposite is true: the outlier saw risk or complexity others missed.

Outliers are gold. If you shame them, you’ll never see them again.

How to Actually Eliminate Anchoring Bias: A Practical Playbook

You can’t erase human psychology, but you can design your process to work with it instead of against it.

Step 1: Separate Understanding From Estimating

Most teams mix these two:

Discuss the story
Someone casually says, “Yeah, seems small”
Then you “estimate”

By then, the anchor is already in the water.

Do this instead:

Clarify the story first
- Ask: “What exactly is in scope?”
- Ask: “What is explicitly not in scope?”
- Ask: “What’s the acceptance criteria?”
- Ask: “What’s the worst-case scenario?”
Ban size language during clarification
No “small,” “big,” “quick,” “easy,” or numbers. Only questions and assumptions.
Only once everyone says “I understand the work” do you move to estimation.

This keeps the conversation anchored on clarity, not size.

Step 2: Use Anonymous, Simultaneous Voting

This is non-negotiable if you’re serious about reducing anchoring.

Minimum bar:

Everyone picks a number privately
All estimates are revealed at the same time
No one sees anyone else’s estimate before committing

You can do this with:

Physical cards (if you’re disciplined)
Online tools that hide votes until everyone has chosen

The anonymity matters. People estimate more honestly when they’re not bracing for judgment.

Step 3: Force the Conversation Around Disagreement

Anchoring thrives when nobody wants to rock the boat.

After revealing estimates:

Identify the spread
- “We have 3, 5, 5, 8, and 13. Good, there’s something to talk about.”
Ask the extremes first
- Ask the lowest: “What assumptions led you to that?”
- Ask the highest: “What risks or work are you seeing?”
Don’t look for the average; look for missing information
- Are we missing test cases?
- Integration complexity?
- Unclear dependencies?
Re-vote anonymously after discussion
- Don’t negotiate to a number (“Can we all agree on 5?”)
- Let people update privately and reveal again

Often, the second round converges—but now it’s informed convergence, not anchored conformity.

Step 4: Make Seniors Go Last (Or Stay Quiet Until Voting)

If you have strong personalities or senior folks in the room, you need guardrails.

Options:

Seniors vote silently and reveal with everyone else
No commentary before the first reveal.
Or: Seniors don’t estimate, they only clarify
They answer questions, highlight risks, but never say numbers.
Or: Seniors speak after hearing juniors’ reasoning
This reverses the usual anchoring flow.

The goal isn’t to muzzle experts; it’s to prevent their status from becoming the default anchor.

Step 5: Change the Unit: Estimate Risk and Complexity, Not Time

Anchoring is worse when you estimate “how long” something will take. People anchor on calendar time they’ve seen before.

You get better outcomes when you estimate:

Relative complexity (“Is this similar to our 5-point reference story?”)
Risk and uncertainty (“How much could this blow up?”)
Unknowns (“How many things do we think we know but might be wrong about?”)

Practical tactic:

Maintain reference stories for 1, 3, 5, 8, 13
During estimation:
- “Is this more like our ‘1’ login bug fix, or our ‘5’ new API endpoint?”
This anchors to shared examples, not arbitrary numbers.

Step 6: Limit Re-Use of Previous Estimates as Anchors

“Last time we did this, it was a 3” is one of the sneakiest anchors.

Sometimes that’s useful; often it’s lazy.

Guardrails:

Only reference past estimates after the first anonymous vote
Use them as a sanity check, not a starting point
Ask: “What’s different this time?” before adjusting toward past numbers

Concrete Facilitation Patterns You Can Steal

Here are ready-made patterns you can run in your next refinement.

Pattern 1: Silent Read, Question-Only Round, Then Estimate

Everyone silently reads the story and acceptance criteria.
One round: only clarifying questions, no opinions or size words.
Confirm shared understanding: “Anyone still unclear on what we’re building?”
Anonymous, simultaneous estimate.
Discuss extremes, re-vote if needed.

Pattern 2: “Assumption Listing” Before Estimating

Before voting:

Ask each person to silently write 2–3 assumptions:
- “We’re reusing existing component X”
- “No new external API is needed”
- “Design is already approved”

Then:

Share assumptions
Spot mismatches (“Wait, design is not approved”)
Only then estimate

This forces thinking about uncertainty instead of guessing a number that others will then anchor to.

Pattern 3: Red/Yellow/Green Risk Tagging

Alongside points, ask for a simple risk tag:

Green – we’ve done this many times, low uncertainty
Yellow – some unknowns, but manageable
Red – many unknowns, dependencies, or new tech

Run this as a separate, anonymous vote if you can. When you have a 3-point story with “Red” risk from half the team, that’s a signal: the point estimate is probably anchored and misleading.

Tools and Techniques That Actually Help (Without the Hype)

You don’t need fancy tools to fight anchoring, but the right ones make it easier to enforce good habits.

Look for tools that:

Support anonymous, simultaneous voting
Don’t show others’ estimates until everyone has voted
Make it easy to run quick sessions without setup friction
Integrate with your backlog tool so you’re not copying numbers around

For example, tools like ScrumPoi offer anonymous planning poker plus retrospectives, with no per-user cost and no sign-up required for quick sessions, which makes it easier to normalize unbiased estimation in real workflows.

The Real Goal: Better Conversations, Not “Perfect” Estimates

You will never fully eliminate anchoring bias. Humans anchor. That’s how our brains work.

But you can design your estimation process so that:

No one person’s opinion becomes the default
Disagreement is surfaced, not suppressed
Risk and uncertainty are visible, not hidden under a single number
Juniors feel safe giving a 13 when everyone else shows a 3

If your estimation meetings end with numbers but not with better shared understanding, you’re doing it wrong.

Start with three changes:

No talking about size before anonymous voting.
Simultaneous, anonymous estimates every time.
Outliers are celebrated and explored, not corrected.

Do just those consistently for a month, and watch how your estimates—and your conversations—change.