Cognitive Biases in Agile Estimates
Your team isn’t bad at estimating because of a lack of technical skill. Estimates go off track because humans are predictably irrational. Understanding these biases is the first step to fighting them.
Anchoring Bias
What it is: The first number we hear influences every subsequent estimate.
In practice: The tech lead says “this should be about 3 points” and the rest of the team unconsciously anchors to that value.
How to fight it: Simultaneous voting (Planning Poker). Everyone votes before seeing anyone else’s number.
Dunning-Kruger Effect
What it is: People with less experience in a domain tend to overestimate their ability, while experts tend to underestimate.
In practice: The junior says “it’s just a CRUD, 1 point” while the senior who knows all the edge cases is thinking “13 points.”
How to fight it: Discuss divergences. Always ask the person who voted lowest: “What makes you think it’s straightforward?”
Confirmation Bias
What it is: We seek out information that confirms our existing beliefs and ignore contradictory evidence.
In practice: The team decides a task is easy and only voices facts that support that view, overlooking obvious risks.
How to fight it: Pre-mortem — “Imagine we failed. What went wrong?” This forces the team to consider negative scenarios.
Sunk Cost Fallacy
What it is: We keep investing in something because we’ve already put a lot into it, even when it no longer makes sense.
In practice: “We’ve already spent 3 days on this, let’s push through” even when rewriting from scratch would be faster.
How to fight it: Evaluate decisions based on future cost, not past investment. “If we hadn’t started yet, would we approach it this way?”
Overconfidence Bias
What it is: We tend to assume the best-case scenario, even when historical data says otherwise.
In practice: “This time will be different” after three consecutive sprints of incomplete delivery.
How to fight it: Use historical velocity and lead time data as your baseline, not gut feel.
Availability Bias
What it is: We estimate based on the most recent or memorable examples, not the actual distribution.
In practice: The last API integration went terribly wrong, so every subsequent one gets massively overestimated.
How to fight it: Look at aggregated data (average of the last 5 similar items), not individual memories.
Framing Effect
What it is: The way a question is asked influences the answer.
In practice:
- “Can we get this done in 1 sprint?” -> tendency to say yes
- “How many sprints do we need to do this properly?” -> more realistic answer
How to fight it: Ask neutral questions. Not “can we do it?” but “how long will it take?”
Anti-Bias Checklist for Estimation Sessions
- Simultaneous voting (anti-anchoring)
- Discuss divergences (anti-Dunning-Kruger)
- Pre-mortem for complex items (anti-confirmation bias)
- Historical data at hand (anti-overconfidence)
- Neutral questions from the facilitator (anti-framing)
- Multiple reference points (anti-availability)
Conclusion
Cognitive biases are invisible but powerful. We can’t eliminate them — we’re human. But with structured processes like Planning Poker, historical data, and techniques like the pre-mortem, we can significantly reduce their impact on our estimates.