The Psychology Behind Planning Poker: Why Anchoring Bias Ruins Your Estimates

Your Planning Poker Is Lying to You (And You Probably Know It)

You’ve been there:

• You run a planning poker session.
• Someone blurts out “this feels like a 5” before voting.
• Half the team quietly adjusts their estimate.
• You end up with “consensus”… and a wildly wrong forecast two sprints later.

Then everyone blames “unforeseen complexity” instead of the real culprit: anchoring bias.

Planning poker is supposed to reduce bias. In practice, most teams run it in a way that bakes bias in and then calls it collaboration.

Let’s unpack why — and what to do differently if you actually want estimates you can trust.

---

The Psychology Behind Planning Poker

What Anchoring Bias Really Does to Your Brain

Anchoring bias is simple and brutal:

The first number you hear heavily influences every number you think about afterward — even if you know it shouldn’t.

Classic experiment: people spun a wheel rigged to land on either 10 or 65, then were asked to estimate the percentage of African countries in the UN.

• Group with “10” guessed ~25%
• Group with “65” guessed ~45%

The wheel was random. The number was meaningless. But it still pulled their estimates.

In planning poker:

• A senior engineer says “This is probably a 3.”
• A product owner says “This doesn’t look that big.”
• Someone mentions “this is just like that last 2-point story.”

Every one of those statements becomes an anchor. Once it’s out there, nobody is truly independent anymore.

Why Planning Poker Should Work (But Often Doesn’t)

Planning poker is designed around a few good principles:

• Independent estimates
• Relative sizing
• Group discussion on outliers
• Convergence through shared understanding

In theory, that’s great. In practice, most teams quietly violate rule #1 before they even start:

• People discuss the story in detail and start hinting at size.
• Someone says, “This is definitely bigger than that last 3-pointer.”
• A tech lead “frames” the complexity before voting.

By the time cards are revealed, everyone’s brain has been pre-loaded with a range. The actual “vote” is just a performance.

---

How Anchoring Bias Ruins Your Estimates

The Subtle Ways Anchoring Shows Up in Your Sessions

You don’t need someone shouting “It’s a 5!” to anchor a group. It happens in quieter ways:

• Comparative anchors
  “This is similar to that login story we did, that was a 3.”
  Translation: “The correct answer is probably 3, don’t stray too far.”

• Authority anchors
  A senior dev says, “This is pretty straightforward.”
  Everyone else downgrades complexity to avoid looking “junior.”

• Time-based anchors
  “We should be able to do this in a day.”
  Now 1–2 points feel “right,” even if 8 is more realistic.

• Tool-based anchors
  Using Jira story numbers as reference: “The last one was SP-123, that was a 2.”
  You’ve now anchored to a previous estimate that may have been wrong in the first place.

The Cost: Why Your Velocity Is a Fantasy Number

Anchoring doesn’t just mess up individual estimates. It systematically distorts your entire system:

• Your velocity looks stable… because everyone keeps anchoring to what “fits” the sprint.
• Your roadmap looks believable… because estimates are shaped to match stakeholder expectations.
• Your team looks “predictable”… until reality hits in production and you scramble.

Some real-world patterns you might recognize:

• Stories keep getting split mid-sprint because they were “just a 3” and turned out huge.
• You always seem to “just barely” complete your sprint — suspiciously convenient.
• Stakeholders are shocked when a “small” item drags on for weeks.

This isn’t bad luck. It’s anchored optimism.

---

Common Mistakes: How Teams Accidentally Supercharge Anchoring

Mistake 1: Discussing Size Before Voting

If anyone says a number or hints at size before the reveal, you’ve already lost independence.

Typical anti-pattern:

1. Discuss story.
2. Someone: “This is probably similar to that 5 we did last sprint.”
3. Everyone nods.
4. You play planning poker anyway, as if that didn’t just happen.

What to do instead:
No numbers. No “small/big.” No “similar to that last 3.” Only clarifying questions and assumptions before voting.

---

Mistake 2: Letting Senior People “Frame” the Story

When tech leads or architects dominate the conversation, you get:

• Estimates that mirror one person’s worldview.
• Junior devs who adjust their votes to avoid conflict.
• A false sense of alignment because no one wants to challenge the boss.

If the most experienced dev always speaks first, you’re not estimating — you’re rubber-stamping.

---

Mistake 3: Open Voting or Visible Cards

If your tool or process shows votes as they come in:

• Early votes anchor later voters.
• People hesitate to pick a number far from the majority.
• You see convergence, but it’s not true convergence — it’s social pressure.

This is the same reason anonymous surveys work better than “show of hands.”

---

Mistake 4: Treating “Consensus” as the Goal

Teams get obsessed with “getting to a single number” instead of:

• Surfacing uncertainty
• Exposing different mental models
• Identifying risk

When your main goal is consensus, you unconsciously:

• Push dissenting votes toward the middle.
• Downplay edge cases (“Let’s not overcomplicate it.”).
• Pick a number that feels comfortable, not accurate.

Consensus isn’t the win. Shared understanding is.

---

Mistake 5: Estimating to Fit the Sprint

If you’re adjusting estimates to make the sprint “look good,” you’ve stopped estimating and started storytelling.

Examples:

• “If we call these all 3s, we can fit exactly 8 stories. Nice.”
• “Let’s not call this an 8, it’ll mess up our velocity.”
• “We can’t have too many 13s this sprint.”

You’re anchoring on capacity, not complexity. That’s how you end up with “perfectly filled” sprints and consistently wrong delivery dates.

---

How to Run Planning Poker Without Getting Destroyed by Anchoring

Step 1: Separate Clarification from Estimation

Make this a hard rule:

1. Clarify first
   • What’s in scope?
   • What’s explicitly out of scope?
   • What assumptions are we making?
2. No sizing language
   • Ban words like “small,” “quick,” “trivial.”
   • Ban references to specific point values.
3. Estimate only after clarity
   • Then and only then: everyone votes silently.

If someone slips and mentions size, stop and reset:
“Cool, but let’s park that. Everyone vote independently first.”

---

Step 2: Make Voting Anonymous and Simultaneous

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

• No verbal estimates.
• No “type your number in chat” where people can see order.
• No revealing votes until everyone has locked theirs in.

Use tools or techniques that enforce:

• Anonymous voting
• Simultaneous reveal

This alone cuts a huge chunk of anchoring.

---

Step 3: Force the Outliers to Speak First

When you reveal the votes:

• Identify the lowest and highest estimates.
• Ask them to explain their reasoning first.
• Everyone else listens without interrupting.

Why this works:

• You get the full range of perspectives.
• You reduce the “majority anchor.”
• You normalize disagreement as useful, not problematic.

Then you can decide:

• Do we re-vote?
• Do we split the story?
• Do we add acceptance criteria?

---

Step 4: Use Points to Express Uncertainty, Not False Precision

Stop pretending points are precise. They’re not. Use them like this:

• 2 vs 3: We understand it well, small-ish.
• 5: More moving parts, some uncertainty.
• 8+: We don’t understand this well enough yet.

If you’re constantly debating between “3 or 5” for 10 minutes, you’re missing the point. The real question:

Do we understand this work well enough to commit to it?

If not, spike it, slice it, or clarify it. Don’t argue over Fibonacci numbers.

---

Step 5: Decouple Estimates from Performance Judgement

If people feel judged by their estimates, they will:

• Anchor on “safe” numbers.
• Avoid high estimates to not look slow.
• Converge toward whatever the team lead tends to pick.

Make it explicit:

• Estimates are not performance reviews.
• Overestimation is not “bad.”
• Underestimation is not “heroic.”

If your organization uses velocity to compare teams or individuals, anchoring will always win. Fix that cultural problem first.

---

What Not to Do in Your Next Planning Poker Session

Avoid these traps:

• Don’t let anyone say a number before voting.
• Don’t show votes in real-time as they’re submitted.
• Don’t let the most senior person summarize the story solo.
• Don’t estimate to hit a target velocity.
• Don’t treat disagreement as something to “get past quickly.”

Instead, aim for:

• Independent thinking
• Clear assumptions
• Honest uncertainty
• Visible disagreement

That’s where the value is.

---

Tactical Changes You Can Make This Week

Here’s a concrete, no-hand-wavy checklist you can apply in your next 2–3 sessions.

Before the Session

• Prepare stories with:
  • Clear acceptance criteria
  • Explicit “out of scope” notes
• Decide on a hard rule: no size talk before voting
• Pick a tool or format that supports:
  • Anonymous voting
  • Simultaneous reveal

During the Session

1. Clarify

   • Let devs ask implementation questions.
   • Let testers ask edge-case questions.
   • Let PO clarify business rules.
   • Write assumptions down where everyone can see them.

2. Vote

   • Everyone votes silently.
   • No one talks about size until all votes are in.

3. Discuss Outliers

   • Ask highest and lowest to explain first.
   • Focus on what they’re assuming, not just the number.
   • Capture newly discovered scope or risks.

4. Decide

   • Re-vote after discussion.
   • If still wide spread:
     • Split the story, or
     • Add a spike, or
     • Defer until more is known.

After the Session

• Track:
  • Which stories were way off?
  • Were they anchored low due to optimism?
  • Were they anchored high due to fear or unknowns?
• Use retrospectives to:
  • Call out when someone anchored the group.
  • Adjust rules or facilitation to prevent repeats.

Tools can help enforce good behavior, but they won’t fix a team that’s afraid to disagree.

---

Using Tools to Reduce Anchoring (Without Turning It into a Sales Pitch)

If you’re going to use a digital tool, pick one that enforces your process instead of working against it:

• Anonymous voting by default
• Simultaneous reveal
• Easy to spin up (no 10-minute login dance)
• Integration with your backlog tool (e.g., Jira)

For example, teams I’ve worked with have used ScrumPoi — a free planning poker and retrospective tool — specifically because its anonymous voting and no-signup sessions make it easier to avoid anchoring and just get straight to real estimates.

---

The Bottom Line: Stop Pretending, Start Estimating

Planning poker isn’t broken.

The way most teams run it is.

If your sessions look like:

• Someone suggests a number.
• Everyone else orbits around it.
• You all nod and move on.

You’re not doing estimation. You’re doing anchored consensus theater.

Strip it back to what actually works:

• Independent thinking
• Anonymous voting
• Outlier-focused discussion
• Estimates that express uncertainty, not bravado

If you fix the psychology, the mechanics of planning poker start working again. If you don’t, no tool, deck, or Fibonacci sequence will save your estimates from anchoring bias.