What Estimation Is For

Estimation does three jobs, and teams that conflate them end up frustrated with all three.

Job 1: Shared understanding. When a team estimates a ticket together, the number is a side effect. The real output is the conversation. One engineer says "that's a small change — swap the endpoint and update the tests." Another says "wait, that endpoint is behind a feature flag that three other services depend on." The gap between their estimates is the gap between their mental models of the work. Surfacing that gap before the work starts is worth more than the number ever will be.

Job 2: Capacity planning. A team with 10 engineers and a two-week sprint has a finite amount of work it can absorb. Estimation — even rough estimation — tells you whether you're loading 80% of capacity or 140%. Without it, sprint planning is guesswork, and "we committed to too much" becomes a recurring retrospective theme.

Job 3: Prioritization. A feature that delivers moderate value and costs a small effort is a different conversation than a feature that delivers the same value and costs a large effort. Estimation gives product and engineering a shared language for making trade-offs. Without it, prioritization defaults to whoever argues loudest.

Some work genuinely can't be estimated, and pretending otherwise produces numbers that mislead more than they inform.

A ticket that says "investigate why the payment webhook fails intermittently" isn't estimable. The engineer doesn't know if the root cause is a race condition, a third-party API timeout, a misconfigured retry policy, or something else entirely. Estimating it as a "medium" just assigns a number to ignorance — and now the sprint plan treats that number as if it means something.

The honest answer is "I don't know, and I need a spike to find out." A spike is a time-boxed investigation — typically half a day to two days — whose output isn't working code but information. After the spike, the team knows enough to estimate the actual fix. Spikes aren't a failure of estimation; they're estimation working correctly by admitting its own limits.

The same applies to genuinely novel work: a new integration with an unfamiliar API, a migration to a technology the team hasn't used, or a performance problem with no obvious bottleneck. Forcing an estimate on these tickets doesn't produce useful information — it produces a number the team feels obligated to hit and a plan built on fiction.

Teams that obsess over estimation accuracy are optimizing the wrong thing. A team whose estimates are consistently off by 30% but who use the estimation conversation to surface assumptions, catch scope gaps, and align on approach is getting more value from estimation than a team whose numbers land perfectly but who estimate in silence.

The number is a byproduct. The conversation is the product. When two engineers estimate the same ticket differently, that disagreement is information — one of them knows something the other doesn't, or they're imagining different implementations. Resolving that disagreement before work starts prevents rework, catches missing requirements, and builds shared context across the team.

This is why estimation methods that force conversation (like planning poker, where everyone reveals simultaneously) outperform methods that don't (like one person announcing a number and asking "does that sound right?"). The reveal isn't about the number — it's about the gap. A ticket where everyone shows a 3 is boring. A ticket where one person shows a 2 and another shows an 8 is where estimation earns its keep.