What Are Estimation Anti-Patterns?
An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. In estimation, anti-patterns are cognitive biases and process failures that systematically destroy accuracy.
Unlike simple mistakes (which are random), anti-patterns are repeatable, predictable failures. They feel natural in the moment but consistently produce bad outcomes. Worse, teams often don't realize they're doing them.
This guide covers 10 deadly anti-patterns, how to identify them in your team, their measurable impact, and how planning poker specifically prevents them. Not theory—concrete cognitive science with real fixes.
The Anchor Effect
First estimate mentioned heavily influences all subsequent estimates, even when it's wildly wrong.
📍 Real World Example
"Senior dev says "probably 3 points" before voting. Everyone suddenly thinks 3-5 range, even though junior dev was thinking 13."
Accuracy Impact
-40% to -60% (estimates cluster around arbitrary anchor)
Team Morale
Junior devs stop sharing concerns
Delivery Predictability
Consistent under-estimation leads to sprint failures
Before (Problem)
Scenario: Team discusses story. Lead says "seems like a 5." During voting, everyone picks 3, 5, or 8.
Result: Final estimate: 5 points. Actual effort: 13 points. Sprint failed.
After (Solution)
Scenario: Team discusses story. No numbers mentioned. Everyone votes simultaneously. Votes: 3, 8, 8, 13.
Result: Discussion reveals complexity. Re-vote: 8, 8, 13, 13. Breaks into smaller stories.
🃏 How Planning Poker Prevents This
Simultaneous card reveal eliminates anchoring. Nobody knows what others think until all cards are down. First opinion has no special weight.
⚡ Quick Fix You Can Implement Today
Ban any number talk before voting. Facilitator says: "No estimates out loud until we vote."
Authority Bias
Team defers to the highest-ranking person's estimate, regardless of who has actual implementation knowledge.
📍 Real World Example
"CTO joins planning session. Estimates 2 points for database migration. Team knows it's 8+ but votes 3-5 to stay close."
Accuracy Impact
-50% to -70% (authority trumps technical reality)
Team Morale
Creates learned helplessness and disengagement
Delivery Predictability
Developers protect themselves with padding elsewhere
Before (Problem)
Scenario: VP says "this is straightforward, right?" Team members hesitantly nod and estimate 3 points.
Result: Developers work overtime to hit the estimate they didn't believe.
After (Solution)
Scenario: All cards revealed simultaneously. VP's 2 vs developer's 8 visible to everyone. Discussion required.
Result: VP learns why it's complex. Estimate adjusted. Or story de-scoped.
🃏 How Planning Poker Prevents This
Equal visibility of all votes. Outliers (including from junior members) trigger mandatory discussion. Authority can't silently dominate.
⚡ Quick Fix You Can Implement Today
Highest-ranking person votes last in physical sessions. Or use digital tool with forced simultaneous reveal.
Optimism Bias
Team consistently estimates based on the best-case scenario, ignoring historical evidence of delays.
📍 Real World Example
"Team estimates API integration at 5 points because "the docs look good." Last 3 API integrations took 3x longer than estimated."
Accuracy Impact
-30% to -50% (reality consistently exceeds estimates)
Team Morale
Chronic overcommitment leads to burnout
Delivery Predictability
Stakeholders stop trusting estimates
Before (Problem)
Scenario: Team estimates assuming no bugs, perfect documentation, and no integration issues.
Result: Sprint velocity: 30 planned, 18 delivered. Repeat for 6 sprints.
After (Solution)
Scenario: Facilitator asks: "What went wrong last time we did this?" Highest estimator speaks first.
Result: Team calibrates to realistic complexity. Velocity: 24 planned, 23 delivered.
🃏 How Planning Poker Prevents This
Forces verbalization of concerns. Highest estimator explains what could go wrong. Team can't ignore pessimistic scenarios.
⚡ Quick Fix You Can Implement Today
Add "what could go wrong?" question before every vote. Make highest estimator speak first.
Recency Bias
Estimates heavily weighted by most recent experience, ignoring broader historical data.
📍 Real World Example
"Last story was surprisingly easy (3 points finished in hours). Team estimates similar work at 2-3 when historical average is 8."
Accuracy Impact
-20% to -40% (swings based on recent luck)
Team Morale
Inconsistent expectations create frustration
Delivery Predictability
Velocity becomes unpredictable
Before (Problem)
Scenario: Team had great sprint. Everything went smoothly. Next planning: aggressive estimates across the board.
Result: Regression to mean. Normal blockers return. Sprint fails.
After (Solution)
Scenario: Team references velocity from last 4 sprints, not just last one. Calibrates using historical stories.
Result: Stable estimation. Velocity variance drops from ±40% to ±15%.
🃏 How Planning Poker Prevents This
Built-in reference to previously estimated stories. "This is like that login form we called a 5." Historical grounding.
⚡ Quick Fix You Can Implement Today
Keep a "reference story catalog" with actual outcomes. Always compare to 3+ past examples, not just 1.
Groupthink
Desire for harmony overrides independent critical thinking. Dissenting opinions self-censor.
📍 Real World Example
"Junior dev sees major complexity. Notices everyone else voting low. Changes vote to match to avoid "looking stupid.""
Accuracy Impact
-35% to -55% (hive mind misses risks)
Team Morale
Psychological safety erodes
Delivery Predictability
Hidden complexity explodes mid-sprint
Before (Problem)
Scenario: Quick consensus on 5 points. Nobody challenges it. Feels efficient.
Result: Story takes 20 hours (13 points). Post-mortem reveals 3 people had concerns but stayed quiet.
After (Solution)
Scenario: Even unanimous votes get "last call for concerns." 30 seconds of silence. Junior dev speaks up.
Result: Hidden API deprecation discovered. Story re-scoped before sprint starts.
🃏 How Planning Poker Prevents This
Anonymity until reveal. Can't see what others think. Forced to form independent opinion first.
⚡ Quick Fix You Can Implement Today
Mandatory "devil's advocate" role rotates each session. Their job: argue for higher estimate.
Sunk Cost Fallacy
Refusing to adjust estimates because "we already committed" even when new information emerges.
📍 Real World Example
"Mid-sprint, team discovers story is 3x more complex. "We estimated 5, let's make it work." Result: cut corners, tech debt."
Accuracy Impact
Appears accurate (hit estimate) but quality suffers
Team Morale
Pressure to sacrifice quality breeds resentment
Delivery Predictability
Velocity looks stable but debt accumulates
Before (Problem)
Scenario: Story estimated at 5. Turns out to be 13. "We committed, we deliver." Team works nights.
Result: Delivered on time. Created 20 points of hidden tech debt.
After (Solution)
Scenario: Story proves bigger. Team stops work, splits it, and moves portion to next sprint.
Result: Delivered quality work. Next sprint properly planned with new info.
🃏 How Planning Poker Prevents This
Estimates are learning tools, not contracts. Planning poker culture: estimates reflect knowledge at that moment, not promises.
⚡ Quick Fix You Can Implement Today
Retrospective question: "Did we sacrifice quality to hit estimates?" If yes, your culture is broken.
Planning Fallacy
Underestimating time needed despite knowing previous similar tasks took longer than planned.
📍 Real World Example
"Team has never finished auth implementation in one sprint. Estimates new auth at 8 points (one sprint). It takes 21."
Accuracy Impact
-40% to -60% (systematic under-estimation)
Team Morale
Repeated failure creates defeatism
Delivery Predictability
Roadmaps consistently slip
Before (Problem)
Scenario: Team estimates database migration at 5 points. Last 3 migrations averaged 15 points.
Result: Migration takes 13 points. "Who could have predicted this?"
After (Solution)
Scenario: Team checks: "Last 3 times we did X, what happened?" Data: 13, 18, 21 points.
Result: Estimates 20 points. Splits across 2 sprints. Finishes in 18.
🃏 How Planning Poker Prevents This
Explicit reference to past work. "Remember the last time we..." becomes part of discussion. History informs future.
⚡ Quick Fix You Can Implement Today
Track actuals vs estimates for similar work types. Apply multiplier to new estimates in that category.
Availability Heuristic
Estimating based on what's easy to remember rather than what's statistically likely.
📍 Real World Example
"Team remembers one freak bug that took 2 days. Estimates all similar work at 8+ points, even though 90% take 2-4 hours."
Accuracy Impact
-25% to -45% (dramatic over/under based on vivid memories)
Team Morale
Inconsistent estimates confuse stakeholders
Delivery Predictability
Capacity planning becomes impossible
Before (Problem)
Scenario: Team remembers painful AWS deployment. Estimates all cloud work at 13 points, even config changes.
Result: Over-estimated. Finished early. Looks good but unrealistic planning.
After (Solution)
Scenario: Team reviews last 10 cloud stories. 8 were 2-5 points. 2 were outliers at 13+.
Result: Estimates based on median (5) with noted risks, not memorable outliers.
🃏 How Planning Poker Prevents This
Structured discussion surfaces statistical thinking. "What usually happens?" vs "What memorably happened once?"
⚡ Quick Fix You Can Implement Today
When team cites an example, ask: "How often does that happen?" Force percentage thinking.
Ego Depletion
Estimation quality degrades as session drags on. Late estimates are rushed and inaccurate.
📍 Real World Example
"Hour 1: thoughtful 10-minute discussions per story. Hour 3: "just call it a 5 and move on.""
Accuracy Impact
-15% to -30% for stories estimated after 90 minutes
Team Morale
Frustration with long sessions
Delivery Predictability
Later stories consistently mis-estimated
Before (Problem)
Scenario: 3-hour planning session. 40 stories. Last 15 stories estimated in 20 minutes total.
Result: First sprint third: accurate. Last third: chaos.
After (Solution)
Scenario: Planning capped at 90 minutes. Remaining stories moved to refinement session.
Result: Consistent estimation quality. Velocity variance drops.
🃏 How Planning Poker Prevents This
Built-in time consciousness. When voting slows and discussions shorten, facilitator calls break or ends session.
⚡ Quick Fix You Can Implement Today
Hard stop at 90 minutes or 15 stories. Whichever comes first. Schedule second session if needed.
Curse of Knowledge
Experts can't remember what it's like to not know something. Under-estimate complexity for others.
📍 Real World Example
"Senior dev who wrote the caching layer estimates caching work at 2 points. Junior dev implementing it needs 5 days (13 points)."
Accuracy Impact
-30% to -50% when expert estimates but doesn't implement
Team Morale
Implementers feel set up to fail
Delivery Predictability
Estimates disconnected from who does work
Before (Problem)
Scenario: Expert estimates based on their speed. "I could do this in 3 hours." Assigns to junior dev.
Result: Takes 2 days. Blamed on junior dev being "slow."
After (Solution)
Scenario: Team asks: "Who's implementing this?" Junior dev votes. Their estimate carries weight.
Result: Expert provides context. Junior dev estimates realistic complexity for their skill level.
🃏 How Planning Poker Prevents This
Everyone votes, including implementer. Implementer's estimate can't be ignored. Discussion reveals knowledge gaps.
⚡ Quick Fix You Can Implement Today
Rule: If you're not implementing, your vote is advisory only. Implementer's estimate wins ties.
How to Identify Anti-Patterns in Your Team
Anti-patterns are often invisible to teams experiencing them. Here's a diagnostic checklist to run after your next estimation session:
Scoring: If you see 3+ warning signs, your estimation process is compromised. 5+ means you're getting near-zero value from estimation. 8+ means you should stop estimating until you fix the process.
The Compound Impact of Bad Estimation Habits
Anti-patterns don't exist in isolation. They compound. A team experiencing Authority Bias + Anchor Effect + Optimism Bias isn't 3x worse at estimation—they're exponentially worse.
The Death Spiral
Stage 1: Estimates are inaccurate. Team misses sprint goals.
Stage 2: Stakeholders stop trusting estimates. Pressure increases to "just commit."
Stage 3: Team pads estimates defensively. Stakeholders apply pressure to reduce padding.
Stage 4: Estimation becomes political theater. No one believes the numbers. Process provides zero value.
How Planning Poker Prevents Common Anti-Patterns
Planning poker isn't just a technique—it's a systematic defense against cognitive biases. Here's how its core mechanics prevent the anti-patterns listed above:
Simultaneous Card Reveal
Nobody knows what others think until all votes are visible. First opinion and highest rank carry no special weight.
Mandatory Discussion of Outliers
Highest and lowest estimators must explain their reasoning. Forces team to consider both best and worst case.
Reference to Historical Stories
Team calibrates against past work: "This is like that API we called an 8." Historical grounding prevents optimism.
Time-Boxed Sessions
Hard stop at 90 minutes preserves estimation quality. Remaining stories move to next session.
Estimates as Snapshots, Not Contracts
Culture: estimates reflect knowledge at planning time. New info = new conversation, not "make it fit."
Break Your Anti-Patterns
Run a planning poker session with proper mechanics. Simultaneous reveal. Outlier discussion. Historical calibration. No shortcuts. See the difference immediately.
Create Free Planning Poker RoomNo signup. No credit card. Just better estimation in 60 seconds.