Why Estimation Is Hard (and Why We Do It Anyway)
Estimating how long software work will take is famously unreliable. Studies consistently show that developers underestimate by 2-3x on average — a phenomenon called the planning fallacy, first described by psychologists Daniel Kahneman and Amos Tversky. This isn't because developers are bad at estimating — it's because software development involves discovering unknowns, and you can't accurately estimate what you don't yet know. Every estimate is really a statement about your current understanding, not a prediction of the future.
Despite this, stakeholders need some sense of when things will be done. The goal of estimation is not precision — it's relative sizing and risk detection. If one task is estimated as "small" and another as "enormous," that difference is useful even if neither estimate is accurate in absolute terms. Estimation also forces the team to think through a problem before starting it, which surfaces hidden complexity early when it's cheap to address.
Common Estimation Techniques
Story Points (Fibonacci Scale):
Teams assign abstract numbers (1, 2, 3, 5, 8, 13, 21) to stories based on complexity, uncertainty, and effort — not hours. A "5-point story" is roughly 2-3x the effort of a "2-point story." The Fibonacci sequence is used because the gaps grow larger as numbers increase, reflecting the reality that larger tasks have proportionally more uncertainty. You can't meaningfully distinguish between a "17-point story" and an "18-point story," but you can meaningfully distinguish between a "5" and a "13."
A common technique is Planning Poker: each team member privately selects a number, all reveal simultaneously, and the team discusses any large disagreements. If one person says "3" and another says "13," the conversation that follows ("I assumed we'd reuse the existing API" vs. "That API doesn't support this use case") is where the real value lies. The number is almost secondary to the discussion it generates.
T-Shirt Sizing (XS, S, M, L, XL):
A simpler alternative. Less precise, but faster and less contentious. Useful for roadmap-level planning where you need rough sizing across dozens of items without the overhead of a full planning poker session. A common mapping: XS = 1-2 points, S = 3 points, M = 5 points, L = 8 points, XL = 13+ points (and should probably be split).
Time-based estimates:
"This will take 3 days." Simple, but creates a false sense of precision and invites micromanagement ("It's day 4, why isn't it done?"). Time estimates also conflate effort with calendar time — a task that takes 3 days of focused work might take 2 weeks of calendar time if the engineer is context-switching between three projects.
The #NoEstimates Movement
Some teams have abandoned estimation entirely, arguing that the time spent estimating could be spent building. Instead, they:
- Break all work into similarly-sized small items (1-3 days each).
- Track throughput (how many items completed per week).
- Forecast using historical throughput: "We complete ~8 items/week, there are 24 items remaining, so ~3 weeks."
This approach works well for mature teams with consistent item sizing. It fails when items vary wildly in size or when stakeholders need date commitments for external dependencies (a product launch, a conference demo, a regulatory deadline). In those cases, some form of estimation is unavoidable — the question is how to do it with appropriate humility about its accuracy.
Communicating Estimates Honestly
The most common estimation failure is not the estimate itself — it's presenting it without uncertainty bounds. "This will take 3 weeks" sounds like a commitment. "Based on similar past work, I'd estimate 2-4 weeks, with the main risk being the third-party API integration" is honest and actionable. Senior engineers learn to attach confidence levels and named risks to every estimate, which gives stakeholders the information they need to make real decisions.
Key Point: The value of estimation is not the number — it's the conversation. When a team debates whether something is a "3" or an "8," they're surfacing hidden complexity, unstated assumptions, and missing requirements. If your estimation process doesn't generate these conversations, it's theater. And if your estimates are consistently wrong in the same direction (always underestimating), that's a signal to examine your process: are you accounting for testing, code review, deployment, and documentation, or just the "coding" portion?