What Estimation Doesn't Give You

An estimate is a forecast, not a contract. The moment a team treats an estimate as a commitment — "you said it was a 5, so it should be done by Wednesday" — estimation stops being a planning tool and becomes a punishment mechanism. Engineers respond by padding estimates to protect themselves, which makes the estimates useless for planning, which makes stakeholders push harder for "accurate" numbers, which makes engineers pad more. The cycle is predictable and common.

The distinction matters most at the boundary between engineering and the rest of the organization. Inside the team, estimates drive sprint capacity and help identify overloaded weeks. That's fine — the team controls the plan and can adjust mid-sprint. The problem starts when estimates leave the team as delivery promises to sales, executives, or customers. A "we think this is about 13 points of work" becomes "engineering committed to three weeks" in a slide deck the team never sees.

Protecting estimates from becoming commitments is a team discipline and a leadership responsibility. The team should communicate estimates as ranges ("2–4 weeks depending on what we find in the legacy code"), not points. And leaders should resist the pressure to strip the uncertainty out of estimates to make a roadmap look cleaner. The uncertainty is the honest part.

Estimation has a cost: the time the team spends estimating instead of building. For most teams, that cost is reasonable — 30 minutes of estimation saves hours of mid-sprint surprises. But the cost can grow until the ceremony consumes more value than it produces.

Warning signs that estimation has become its own waste:

• Estimation sessions run longer than an hour. If the team is spending 90 minutes estimating a sprint's worth of tickets, the tickets aren't well-defined enough to estimate, or the team is debating implementation details that belong in design discussions, not estimation.
• Nobody uses the estimates after the session. If the estimates go into the tracker and nobody references them during sprint planning, capacity checks, or retrospectives, the team is producing numbers for nobody. Stop estimating those tickets and spend the time elsewhere.
• Re-estimation is routine. If the team regularly re-estimates tickets because scope changed, requirements shifted, or "we understand it better now," the estimation is happening too early. Estimate later, when the work is better defined, or accept that early estimates are rough and don't re-estimate.

The principle is the same one that applies to every piece of process: if it's not creating leverage, it's creating overhead. Estimation should be cheap, fast, and useful. When it becomes expensive, slow, or ignored, scale it back.

The #NoEstimates movement argues that estimation is often unnecessary and that teams can forecast delivery using historical throughput — the number of tickets completed per week — instead of assigning sizes to individual tickets. The argument has merit, and dismissing it as lazy is as wrong as treating it as gospel.

Throughput-based forecasting works like this: if a team consistently completes 10–14 tickets per week, and a project has 45 tickets, the forecast is 3–5 weeks. No estimation session needed. The math relies on two conditions: tickets need to be sliced to roughly similar sizes, and the team needs enough historical data to establish a reliable throughput range. When those conditions hold, the forecast is often more accurate than a bottom-up estimate of each individual ticket.

The catch is discipline. Teams that skip estimation but also skip the slicing discipline end up with no forecasting capability at all — they can't estimate because they've abandoned the practice, and they can't use throughput because their tickets range from one-hour fixes to three-week epics. #NoEstimates without consistent slicing is just #NoInformation.

For most teams, the pragmatic path is somewhere in the middle: estimate lightly (S/M/L), track throughput as a secondary signal, and drop estimation entirely only when the data shows throughput alone is sufficient. The worst choice is estimating heavily and ignoring throughput — that's maximum ceremony for minimum information.