Stop Anchor Bias in Story Pointing: Get Honest Estimates
When the senior architect says "that's a 5" before others vote, the rest of the team gravitates toward 5—even if their gut said 8. Anchor bias is the #1 reason planning poker estimates are inaccurate. Here's how to prevent the loudest voice from dominating your estimation.
The Anchor Bias Problem
Anchoring is a cognitive bias where the first number mentioned disproportionately influences subsequent judgments. Research shows even arbitrary anchors (random numbers) affect expert estimates by 20-40%.
In planning poker, anchoring happens when:
- Senior developers speak first: "This looks like a 3 to me"
- Cards reveal sequentially: First vote shown influences perception of remaining votes
- Facilitator shows bias: "I'm thinking 5, what do you all think?"
- Previous story anchors next: "Last story was 5, this is similar, so..."
- Historical data visible during voting: "We estimated this at 8 last sprint"
Why Anchor Bias Ruins Estimation Accuracy
When junior developers or introverted team members defer to the first number mentioned:
- You lose diverse perspectives on complexity
- Hidden implementation details don't surface
- Estimates skew toward whoever speaks first (usually senior devs)
- Team consensus is false—people aren't genuinely aligned
- Sprint commitments fail because estimates were anchored, not realistic
How Planning Poker Prevents Anchoring
Traditional planning poker was explicitly designed to combat anchor bias:
1. Simultaneous Reveal
All votes must appear at exactly the same moment. No one sees anyone else's estimate before committing their own.
2. Silent Voting
No verbal discussion until after cards are revealed. Forces independent thought.
3. Anonymous Initial Estimates
Some teams hide voter names during first reveal to prevent authority bias ("that's the lead engineer's vote").
But Many Tools Fail at This
Poor implementations of planning poker reintroduce anchor bias:
- Sequential reveals: Votes appear one by one due to network lag
- Visible vote counts before reveal: "5 people voted" changes to "6 people voted" tips someone off
- Real-time vote streaming: Live updates showing cards as they're selected
- Historical estimates shown during voting: "Last time we said 8" anchors current vote
Best Practices to Eliminate Anchor Bias
Use a Tool with True Simultaneous Reveal
Alignlee uses server-side synchronized reveals—all cards appear within 200ms across all screens. No sequential anchoring possible.
Enforce Silence During Voting
Facilitator rule: No one discusses their estimate until all votes are cast. Use Slack's "mute all" or ask participants to physically turn off mics.
Vote Smallest to Largest (Not Seniority)
After reveal, if re-voting is needed, ask the person who voted smallest to explain their reasoning first. Prevents senior developers from setting the anchor on round 2.
Hide Historical Estimates During Voting
Don't display past estimates for similar stories until after current voting completes. Let the team estimate fresh.
Rotate Facilitation
When the same person facilitates every session, their biases become invisible anchors. Rotate the facilitator role weekly.
The "Extreme Outlier" Technique
When votes span widely (2, 3, 5, 5, 13), intentionally ask the extreme outliers to speak first:
- "Let's hear from whoever voted 13—what complexity did you see?"
- Then: "Now let's hear from the 2—what makes this simple in your view?"
This surfaces hidden assumptions before the "middle votes" anchor the discussion.
Recognize Subtle Anchoring in Discussion
Even after reveal, anchoring creeps into conversation:
- "Most people said 5...": Focuses on majority, silences outliers
- "Let's compromise at 5": Averaging is not consensus
- "We're running long, let's just go with 5": Time pressure creates false anchors
Good facilitators prevent these by explicitly asking minority voters to defend their estimates first.
When Senior Developers Should Speak First
Anchor bias prevention doesn't mean silencing expertise. Senior developers should speak first when:
- Explaining technical constraints the team doesn't know yet
- Clarifying the story (not estimating it)
- Surfacing dependencies or risks (facts, not opinions)
But their initial estimate should still be revealed simultaneously with everyone else's.
Measure Your Team's Anchor Bias
Track this metric over 3-5 sprints:
Convergence speed: How many voting rounds until consensus?
- 1 round = healthy independent thought
- 2 rounds = normal, slight anchoring
- 3+ rounds = strong anchor bias (first vote sets pattern, debate goes nowhere)
If you consistently need 3+ rounds, your team is anchoring hard on initial votes.
Start Anchor-Free Estimation Today
Stop letting the loudest voice dictate estimates. Use Alignlee with true simultaneous reveal and silent voting to get honest, unbiased story points.