Anchor bias in planning poker happens when one number reaches the team before they have formed their own estimate, and everyone's vote drifts toward it. The fix is blind voting: everyone commits to a card privately, all cards are revealed at the same moment, and no one says, types, or hints at a number before the reveal. Blind voting only works if you also close the other routes an anchor can take, like a Product Owner saying "this should be quick" or last sprint's estimate sitting in the ticket.
This article lists the anchor sources we see most often, gives a specific fix for each, and explains what blind voting has to include to actually work.
What anchoring is, briefly
Amos Tversky and Daniel Kahneman described anchoring in their 1974 paper Judgment under Uncertainty: Heuristics and Biases. In one of their best-known demonstrations, participants watched a wheel of fortune land on a number, then estimated an unrelated quantity. Their estimates were pulled toward the number on the wheel, even though everyone knew the wheel was random.
The lesson for estimation: an anchor doesn't need to be credible to work. It doesn't even need to be relevant. And telling people "don't be anchored" does little, because people adjust away from the anchor but usually not far enough. That is why planning poker relies on structure (hidden votes, simultaneous reveal) rather than willpower. James Grenning designed the technique, and Mike Cohn popularized it, around exactly this idea, drawing on the older Wideband Delphi method.
Anchoring vs vote copying
They are related but not the same, and the fixes differ.
- Anchoring is unconscious. A developer hears "it's basically a 3," then genuinely believes their 8 was too high and votes 5.
- Vote copying is conscious. A junior developer thinks it's an 8, sees the tech lead's 3, and votes 3 to avoid looking wrong.
Hidden votes and simultaneous reveal stop copying. Anchoring needs more: you have to stop numbers and size words from reaching the team at all before the vote.
The 9 most common anchor sources, and the fix for each
| # | Anchor source | What it sounds like | Fix |
|---|---|---|---|
| 1 | PO frames the size | "This should be a quick one" | PO reads the goal and acceptance criteria only. No size words: quick, small, simple, huge, nightmare. |
| 2 | Senior speaks first | "That's a 5, right?" | No numbers before reveal. Seniors share facts and constraints, not sizes. |
| 3 | Previous estimate visible | Jira field still shows "8" from last quarter | Clear or hide the old estimate before re-estimating. Show it only after the reveal, for comparison. |
| 4 | Facilitator thinks aloud | "I'm guessing around 5, thoughts?" | Facilitators never voice a number. Open with "Cards down." |
| 5 | Deadline or capacity mentioned | "We only have room for 3 points this sprint" | Keep capacity talk for sprint planning. Estimation sizes the work, not what fits. |
| 6 | The last story | "Similar to the last one" (which was a 5) | Compare against agreed reference stories, at least two, one smaller and one larger. |
| 7 | Leaks before reveal | Physical card flipped early, "ugh," a chat message "this is huge" | Silence in voice and chat until reveal. Remote teams: no emoji reactions during voting. |
| 8 | Manager or stakeholder watching | Team votes low because the boss is in the room | Observers don't vote or comment on size. See handling management pressure on estimates. |
| 9 | The first explainer after reveal | Majority voter explains first, outliers fold | Outliers speak first, lowest and highest. More below. |
Fixing the PO anchor without silencing the PO
The PO's job is to explain value and scope, and that context matters. The rule is about vocabulary, not participation. A useful script for the facilitator, said once at the start of a session:
"PO, please describe what and why. Skip any words about size, like 'quick' or 'big.' The team will tell you the size."
If it slips out anyway mid-session:
"Let's pretend we didn't hear 'quick.' Cards down, independent votes."
Being light about it keeps the PO on side. You'll need to say it maybe twice before it sticks.
Fixing the senior-speaks-first anchor
Expertise isn't the problem. Seniors often know about the legacy module or the vendor's rate limits, and the team needs that. Separate facts from sizes:
- Before the vote, seniors can say: "Heads up, the reporting service has no test coverage."
- They should not say: "So this is at least an 8."
Then they vote like everyone else. If you suspect juniors routinely defer, track it for a few sessions: does the final estimate nearly always match one person's first vote? That's an anchor, not consensus.
Fixing the previous-estimate anchor
Re-estimation (after a split, a scope change, or a long delay) is where old numbers do the most damage. Before the vote, either clear the field or don't screen-share the ticket. After the reveal, it's useful to show the old number: "Last time we said 8. We're now at 13. What changed?" Used that way, the old number is a learning tool rather than an anchor. More on this in re-estimating stories mid-sprint.
Reference stories: anchor or calibration?
Reference stories are a deliberate anchor, and that's fine as long as they're agreed by the team and bracket the story. Showing only one reference ("our login story was a 3") pulls everything toward 3. Showing two ("the CSV export was a 2, the payment retry was an 8") gives a range and lets people place the new story between them. See calibrating story points for building a reference set.
Blind voting: what it has to include
"Blind voting" means no one can see or infer anyone else's vote until everyone reveals together. In practice that requires all of the following:
- Votes are hidden until reveal. Not visible to other participants, and ideally not to the facilitator either. A facilitator who can see votes arriving will react, and reactions leak.
- Simultaneous reveal. All cards appear at once. Physical cards: count down "3, 2, 1, flip." Digital tools: check that cards don't trickle in one by one.
- Silence during voting. No numbers in voice or chat, no "hmm, interesting" from the facilitator, no groans.
- No vote changes after seeing others. If people can switch after a partial reveal, it isn't blind.
- A clean pre-vote environment. No old estimates on screen, no capacity numbers, no "similar to the last one."
Most tools show who has voted (a checkmark), which is fine on its own. It helps you know when to reveal. It becomes a problem only when combined with other leaks, like a tech lead who always votes instantly and always votes low.
Blind vs anonymous
These are different. Blind means votes are hidden until reveal. Anonymous means names stay hidden even after reveal. Blind voting is essential. Anonymity is optional, and it trades away something useful: you can't ask the outlier to explain if you don't know who it is.
Anonymous reveals can help a team with a strong hierarchy for a few sessions. But if people only vote honestly when hidden, the underlying problem is psychological safety, and the protocol below addresses that more directly.
In Alignlee, votes are hidden until reveal and shown with names afterward. There is no anonymous mode, so teams with hierarchy issues should lean on the outlier-first protocol. Each vote also carries a confidence slider, and low-confidence votes count less in the weighted estimate. That gives someone who is unsure but not convinced a way to say so without pretending to agree.
Physical cards in a room
Physical cards leak more than people expect: someone holds their card loosely, someone picks a card with visible confidence, someone sighs at the story. Rules for in-room teams:
- Cards face down on the table, not in hand.
- Facilitator counts down, everyone flips together.
- Nobody touches their card again until discussion is done.
For hybrid teams, have everyone vote digitally, including the people in the room, so remote voters aren't revealing a beat later. See remote planning poker.
Anchoring after the reveal
Simultaneous reveal protects the first vote. The revote is exposed again, because now everyone has heard the discussion. Three practices keep the second round honest.
Outliers speak first, lowest then highest. The middle voters go last or not at all. If the majority explains first, outliers tend to fold without sharing what they saw.
"We've got a 2 and a 13. Sam, what makes this a 2? Then Priya, what's in your 13?"
Watch your summarizing language. These phrases all push toward the middle:
| Avoid | Say instead |
|---|---|
| "Most people said 5..." | "We've got a spread from 3 to 13." |
| "Let's compromise at 5." | "What would have to be true for this to be a 13?" |
| "We're running long, let's go with 5." | "Time's up. Revote once, or park it." |
| "That's a reasonable middle ground." | "Did anyone change their mind? Revote." |
Revote silently. After explanations, cards go down again with no talking. Don't ask for a show of hands ("who's OK with 5?"); that's an open, sequential vote and the most anchored format there is.
What to do when the revote is still split is covered in consensus fatigue and how many rounds to vote.
A short scenario
A hypothetical team is sizing "Add SMS fallback to password reset." While reading the story, the PO says, "This should be quick, it's just the reset flow we already have." Votes come back: 3, 3, 3, 3, 5, 3. Close to unanimous. The facilitator asks the lone 5 anyway. The tester says the SMS vendor has strict rate limits and nobody has written retry handling for it.
The team revotes: 5, 8, 8, 5, 8, 8. They take 8.
Two anchors were in play: the PO's "quick" and "the reset flow we already have" (a reference point the PO chose, not the team). The tester's concern only surfaced because the facilitator asked the outlier even when the vote looked settled. The next session, the facilitator reminds the PO up front: what and why, no size words.
Signs your team is anchoring
- The final estimate almost always matches one specific person's first vote.
- First votes cluster tightly on stories where the PO or a senior said something about size.
- People change their vote immediately after reveal without new information.
- Juniors rarely vote outside the middle of the range, even on unfamiliar work.
- Re-estimated stories come out at exactly the old number.
If you see two or more, run a few sessions with stricter rules (no size words, outliers first, old estimates hidden) and compare.
FAQ
What is anchor bias in planning poker? It's the tendency for votes to drift toward the first number or size cue the team hears, such as a senior developer saying "that's a 5" or a PO calling a story "quick." Tversky and Kahneman showed that even random anchors pull estimates, which is why planning poker hides votes until a simultaneous reveal.
How do you prevent vote copying in planning poker? Use blind voting: hidden votes, a simultaneous reveal, and no numbers spoken or typed before the reveal. Revote silently instead of by show of hands, and have outliers explain first so the majority's view doesn't set the second round.
What is blind voting in planning poker? Every participant picks a card privately and all cards are revealed at the same moment, so no one sees another vote before committing. It's different from anonymous voting, where names stay hidden after the reveal. Blind voting is essential; anonymity is optional.
How do you reduce anchoring bias in estimation generally? Keep size words and numbers out of the room until people have committed independently, compare against two reference points rather than one, hide previous estimates until after the vote, and ask the person with the most different view to speak first.
Should senior developers stay quiet during planning poker? No. They should share facts, constraints, and risks before the vote, but not their size estimate. Everyone, including seniors, votes at the same time.