Overview
Software estimation has a miserable reputation because it's usually done as confident single-point guessing about inherently uncertain work — then treated as a commitment. The honest practice starts from accepting the uncertainty (the "cone" narrows only as work progresses), expresses estimates as ranges tied to what's known, and increasingly replaces guessing altogether with forecasting from the team's own measured throughput.
Key points
- Why estimates fail structurally: software tasks are novel by definition (repeat work gets automated), unknowns surface during the work, and Hofstadter's law compounds ("it always takes longer, even accounting for Hofstadter's law"). Optimism bias plus anchoring ("can it be done by Friday?") does the rest. An estimate given under pressure is a negotiation, not information.
- Estimate ≠ target ≠ commitment: three different things chronically collapsed into one number. An estimate is a probability distribution; a target is a business wish; a commitment is a promise with consequences — say which one is being asked for, and answer that one.
- Ranges and confidence, not points: "2–4 weeks, 90% confident" carries information; "3 weeks" carries hope. If a single number is forced, know it will be read as the earliest possible date — give the number you'd bet on, not the one that ends the meeting.
- Relative sizing works, ceremony doesn't: comparing tasks to each other (bigger/ smaller than that thing we did) is genuinely easier than absolute dating — that's the defensible core of story points; the pathology is points becoming velocity targets and cross-team currency (Goodhart's law does the rest). Coarse buckets (S/M/L, 1/2/3) capture most of the signal at a fraction of the ritual.
- The best estimator is decomposition: breaking work into thin vertical slices exposes the unknowns now — estimation error hides in the tasks you haven't imagined; a spike (timeboxed investigation) is the honest answer to "we don't know enough to size this yet".
- Forecast from throughput where you can: counting finished items per week and projecting with that distribution (Monte Carlo over historical throughput — the #NoEstimates kernel) forecasts delivery dates from evidence; it needs only that work items be reasonably sliced, and it self-corrects as data accumulates. "When will this batch be done" becomes a percentile, not a promise.
- Planning is replanning: the plan's value is the shared understanding built making it; reality updates it weekly. Communicate slips early — a moved date announced at 30% through is planning; announced the day before, it's an incident.
- To explore: reference-class forecasting, cost-of-delay for sequencing (WSJF), How Big Are Your Potatoes / Software Estimation (McConnell) as anchors, capacity math with meetings-and-interrupts honesty.
Practice
- Elephant Carpaccio (source) — Cockburn's slicing workshop: spec a small app, cut it into ~20 demoable slices, build in 5×8-minute sprints; runnable solo as a slicing-and-timeboxing drill; teaches that vertical slices thinner than you believe possible still deliver value.
- Story-splitting drill (source) — take one real feature and produce ten vertical slices of under a day each, using the splitting patterns; teaches decomposition, the best estimator there is.
- Estimate audit (source) — dig your last dozen "it'll take X" claims out of the journal, compare against actuals, and compute your personal optimism multiplier; teaches reference-class thinking on the only reference class that never lies — your own record.
- Monte Carlo forecast from your own throughput (source) — count finished items per week for recent months and run Troy Magennis's free forecasting spreadsheets over them; teaches "when will this be done" as a percentile instead of a promise.
Related
- Technical debt — the unestimated tax on every estimate.
- Team topologies & Conway's law — dependencies between teams are the biggest schedule risk of all.
- CI/CD & delivery engineering — small slices are both a delivery and an estimation practice.