Estimation Anti-Patterns That Kill Sprint Velocity

Bad estimation practices are sticky. They feel normal, they're hard to attribute to specific sprint failures, and they tend to get worse over time. Here are the patterns worth eliminating.

Anti-pattern 1: Design-by-estimation

The team spends estimation time solving architecture problems. "How would we build this?" turns into a 30-minute design session for every story.

What it costs: Sprint planning takes 4 hours instead of 90 minutes. Design decisions made under time pressure without the right people in the room.

Fix: Defer design questions to a follow-up spike or architecture session. If the approach is unknown, play "infinity" and create a spike. Don't design in the planning session.

Anti-pattern 2: Precision theater

Estimating in story points that subdivide meaninglessly: debating whether something is a 3 or a 4, when the team doesn't have enough calibration to distinguish between them.

What it costs: Time spent on false precision that adds no planning value.

Fix: If you're using Fibonacci, trust the gaps. A 3 and a 5 are meaningfully different. A 3 and a 4 aren't.

Anti-pattern 3: The estimate as contract

Developers are held accountable to their estimates in performance reviews or public tracking. This incentivizes padding, discourages honest uncertainty, and makes planning poker a self-protective exercise rather than a planning tool.

What it costs: Systematic overestimation. Velocity inflates while actual output stays the same.

Fix: Establish explicitly that estimates are forecasts, not commitments. Individual estimates are team property, not individual accountability.

Anti-pattern 4: Re-estimating every sprint

The team re-estimates stories that didn't complete last sprint, often producing a different number just from familiarity. This inflates apparent velocity when carried stories finally close.

What it costs: Corrupt velocity data. Planning inputs that don't reflect reality.

Fix: Keep the original estimate on a carried story. Don't re-estimate unless the scope has materially changed.

Anti-pattern 5: Estimating too far ahead

The team estimates stories that are four or five sprints away. By the time those stories come up, scope has changed, and the estimates are stale.

What it costs: Time wasted on estimates that won't be used, plus false confidence in a roadmap that's based on old assumptions.

Fix: Only estimate stories that are likely to enter a sprint in the next one to two sprints. Keep the distant backlog rough-sized (T-shirt sizes or buckets) rather than point-estimated.

Most estimation problems aren't estimation problems - they're planning culture problems. Fix the norms and the numbers get better automatically.