Someone says "that's a two-day job" before the vote, and suddenly nobody estimates above three. Most teams have seen it happen. It has a name, anchoring bias, and it is the main reason Planning Poker asks everyone to vote in private and reveal at the same time.
This article explains what anchoring is, what research says about it in software estimation, where it creeps into estimation meetings, and which habits keep it under control.
What is anchoring bias?
Anchoring bias is the tendency to rely too heavily on the first number you hear when you estimate something. That first value, the anchor, becomes a starting point, and people adjust away from it too little, even when the anchor is irrelevant or obviously wrong. Psychologists Amos Tversky and Daniel Kahneman described it in 1974 as "anchoring and adjustment", one of the shortcuts people use when they judge under uncertainty. In software teams, the anchor is often a figure said aloud before the vote: a developer's quick guess, a manager's deadline, a client's budget or last year's estimate for a similar feature. Everyone who hears it then estimates closer to it than they would have alone. The effect is strongest when the work is uncertain, which describes most user stories. Planning Poker counters it with one rule: everyone picks a card privately, and all cards are revealed at the same time.
What does research say about anchoring in software estimation?
The effect is one of the best documented in judgement research, and software estimation is no exception.
The original experiment. Tversky and Kahneman spun a wheel of fortune in front of participants, then asked them what percentage of African countries were in the United Nations. People who saw the wheel stop at 10 gave a median answer of 25; people who saw 65 answered 45. A random number moved their estimate by 20 points (Tversky and Kahneman, 1974).
Software estimates. Jorge Aranda and Steve Easterbrook asked 23 participants, mostly graduate students and some industry professionals, to estimate the same project (ESEC/FSE 2005). Some read a remark from a manager who admitted having "no experience with software projects" but guessed 2 months; others read the same remark with 20 months; a control group read no number. The average estimates were 6.8 months with the low anchor, 8.3 months with no anchor and 17.4 months with the high anchor (thesis data). A guess from a self-declared non-expert still doubled the estimate.
Client expectations. Magne Jørgensen's research group at Simula found the same pattern with customer expectations: estimators moved towards what the client hoped for, even when told that this expectation said nothing about the real effort (Jørgensen and Sjøberg, 2004).
In real companies. A field experiment with 46 outsourcing companies found smaller effects than in the lab, but a short deadline in the specification still lowered effort estimates substantially (Jørgensen and Grimstad, 2011).
| Study | Anchor | Effect on estimates |
|---|---|---|
| Tversky and Kahneman, 1974 | A random number from a wheel (10 or 65) | Median answers of 25 vs 45 |
| Aranda and Easterbrook, 2005 | A non-expert's guess (2 or 20 months) | Average 6.8 vs 8.3 (no anchor) vs 17.4 months |
| Jørgensen and Sjøberg, 2004 | The client's expected effort | Estimates moved towards the expectation |
| Jørgensen and Grimstad, 2011 | Irrelevant or misleading project information | Smaller in the field, but a tight deadline still lowered estimates |
Where does anchoring show up in estimation meetings?
Anchors rarely look like anchors. The most common ones:
- The first voice. "Should be quick" or "that's at least an 8" said while the story is presented.
- The most senior person. When the lead developer speaks first, others defer, even when they see risks the lead missed.
- The deadline or the budget. "We need it by the release" quietly becomes "it must be small".
- The Product Owner's opinion. The PO knows the business value, not the technical effort. The Planning Poker rules recommend that the PO answers questions but does not vote.
- The old estimate. A story re-estimated after refinement tends to stay close to its first number.
- Visible votes. In a chat thread or a video call, each number typed or said out loud anchors the people who have not answered yet.
- An AI suggestion shown too early. An assistant's estimate displayed before the vote is one more anchor. Our article on Planning Poker and AI recommends showing it only after the first round.
How does Planning Poker counter anchoring?
Planning Poker, described by James Grenning in 2002 and popularized by Mike Cohn, is built around one idea: collect independent opinions first, discuss second.
- Everyone votes privately. Each estimator picks a card without seeing anyone else's.
- All cards are revealed at once. No vote can influence another, because none is visible before the reveal.
- The extremes explain. The highest and lowest voters say why, which brings out the risks or shortcuts the others missed.
- The team votes again. After the discussion, estimates usually converge, this time for good reasons.
Independent votes are also more honest about disagreement. On the sessions measured on our usage data page, only about a quarter of first votes are unanimous, and around 40% are two steps or more apart on the Fibonacci scale. With anchoring, that disagreement would have stayed hidden behind the first number spoken.
The tool should protect this independence. In Planning Poker Online, nobody can see a vote before the reveal, not even the Scrum Master. A shared spreadsheet or a chat thread where numbers appear one by one breaks the rule.
What else reduces anchoring?
Simultaneous reveal handles the vote itself. These habits handle what happens around it.
| Habit | How to apply it | Anchor it removes |
|---|---|---|
| Give context, not numbers | The PO describes the need and acceptance criteria, never a size or a duration | Business pressure |
| Facilitator stays neutral | The Scrum Master keeps their own estimate to themselves | Authority |
| Rotate who speaks first | After the reveal, alternate between high and low voters | Seniority |
| Talk about deadlines after the vote | Estimate the effort first, then discuss what fits before the date | Deadline |
| Re-estimate from scratch | Hide or ignore the previous estimate when a story comes back | Old estimate |
| Use stable reference stories | Compare with two or three agreed stories, not with whatever was said last | Random numbers |
Reference stories are anchors too, but deliberate and shared ones: the team chose them, everybody knows them and they rarely change. That is the difference between relative estimation and anchoring. Our guide on how to run a Planning Poker session covers these facilitation habits in detail.
Does simultaneous reveal remove anchoring completely?
No. It removes anchoring between votes, not every anchor.
- Discussion before the vote still anchors. If someone mentions a figure while the story is presented, the private vote comes too late. Ask for questions about scope, not opinions about size.
- Second rounds converge on purpose. Moving towards the group after a good argument is the point of the discussion. Moving because of a title or a loud voice is not, which is why the facilitator asks the extremes to explain before anyone re-votes.
- Real-world effects vary. Jørgensen and Grimstad found that field effects were much smaller than laboratory ones, while relevant but misleading information, such as a short deadline, could still weigh heavily. Treat anchoring as a risk to manage, not a certainty.
Frequently asked questions
What is an example of anchoring bias in agile estimation? A typical example of anchoring bias in agile estimation is a developer saying "this is a quick fix" while a story is presented. Even if the story later turns out to touch several services, the team's estimates stay low because everyone adjusted from that first remark instead of estimating the work independently.
Does Planning Poker eliminate anchoring bias? Planning Poker does not eliminate anchoring bias, but it removes its most common source: votes influencing each other. Because every card is chosen privately and revealed at the same time, no estimator sees another number first. Anchors said aloud before the vote, such as a deadline or a quick guess, can still influence the team.
Should the Product Owner vote in Planning Poker? In most teams the Product Owner should not vote in Planning Poker. The Product Owner brings the business context and answers questions, while the Developers estimate the effort of the work. A vote from the person who prioritizes the backlog can act as an anchor, especially if the team feels pressure to agree.
Are reference stories a form of anchoring? Reference stories are a deliberate form of anchoring, and a useful one. The team chooses two or three completed stories, agrees on their size and compares new work with them. Unlike a random remark or a deadline, these references are shared, stable and relevant to the effort, which is what makes relative estimation consistent over time.
Sources
- Amos Tversky and Daniel Kahneman, Judgment under Uncertainty: Heuristics and Biases, Science, 1974
- Jorge Aranda and Steve Easterbrook, Anchoring and Adjustment in Software Estimation, ESEC/FSE 2005, and Jorge Aranda, MSc thesis, University of Toronto, 2005
- Magne Jørgensen and Dag Sjøberg, The Impact of Customer Expectation on Software Development Effort Estimates, International Journal of Project Management, 2004
- Magne Jørgensen and Stein Grimstad, The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates, IEEE Transactions on Software Engineering, 2011
- James Grenning, Planning Poker or How to avoid analysis paralysis while release planning, 2002
- Mountain Goat Software, Planning Poker
Keep your estimates independent
Anchoring starts with a number said too early. Create a free Planning Poker session: every vote stays hidden until the reveal, and the whole team sees the spread at once. No sign-up required. See all the features.
