Estimation & Planning Techniques

Ask a team how long something will take and you will get a number. Ask them later why it took twice as long and you will get a shrug. The gap between the two is not a sign of a bad team. It is the normal, predictable behavior of human beings estimating work they have not yet done. Once you understand why estimates fail, you can build a practice that fails less, and recovers gracefully when it does.

The number was never the point

The first thing to unlearn is the single number. When you say a task is “five days,” you have compressed a wide range of possible outcomes into one falsely precise figure. At the moment you estimate, you know the least you will ever know about the work: requirements are fuzzy, dependencies are hidden, and the surprises are all still in the future. This is the cone of uncertainty. Early estimates can be off by a large factor in either direction, and the range only narrows as you actually do the work.

So the honest unit of estimation is a range, not a point. “Three to nine days” tells the truth that “five days” hides. Everything good in estimation flows from accepting that uncertainty is real and building around it instead of pretending it away.

Why we lowball, every time

Three biases reliably push estimates too low. Optimism bias makes us picture the smooth path where nothing goes wrong. Anchoring drags every estimate toward the first number anyone mentions, so the innocent question “could we do this by Friday?” quietly sets the answer. And under pressure, when a stakeholder clearly wants a small number, the estimate shrinks to please them.

Above all sits the planning fallacy, described by psychologists Daniel Kahneman and Amos Tversky: we underestimate time and cost even when we know that similar past work ran long. The trap is that we estimate from the inside, by imagining the steps of this specific task, and ignore the boring outside view, the statistical record of how similar tasks actually went. Experience alone does not cure it. Someone late on ten projects will confidently underestimate the eleventh. The only reliable fix is to deliberately pull in that outside view.

Size first, time later

Humans are poor absolute clocks but excellent comparators. We guess a song’s length badly yet reliably know which of two songs is longer. Relative estimation exploits this. Instead of predicting duration directly, you compare items to each other using story points (a non-linear scale like 1, 2, 3, 5, 8, 13) or coarse t-shirt sizes. A point bundles effort, complexity, and risk into one judgment.

The clever part is the conversion. You never claim “an eight-point story takes sixteen hours.” Instead you measure how many points your team actually completes per sprint, its velocity, and let that empirical number absorb all the messy reality of meetings, interruptions, and varying individual speed. The moment someone says “a point is two hours,” the abstraction collapses and people start padding. Points measure size; velocity converts size to time.

Three numbers beat one

When an item genuinely needs a date, give three estimates: optimistic (O), most likely (M), and pessimistic (P). The Program Evaluation and Review Technique combines them into a weighted expected value and a measure of uncertainty:

E = (O + 4M + P) / 6 and SD = (P - O) / 6.

Take O = 2, M = 4, P = 12 days. Then E = (2 + 16 + 12) / 6 = 5 days, and SD = 10 / 6 = 1.67 days. Notice the expected value, 5, is higher than the most-likely 4. That gap is the long pessimistic tail being honestly counted, the exact optimism a single guess ignores. For a roughly bell-shaped spread, about 95 percent of outcomes land within two standard deviations, so this is “5 days, very likely under 8.3.”

A subtle, powerful rule applies when you add items up: expected values add directly, but standard deviations do not. You add the variances and take the square root. Because not every task overruns at once, the errors partially cancel, and a plan made of many uncertain items is more predictable in total than any single item.

From estimate to plan

An estimate is not a plan. A plan adds sequencing, calendar reality, and buffers. The wrong way to buffer is to pad each task in secret, because hidden padding gets spent and you lose all visibility. The right way is to estimate honestly, then pool the uncertainty into one visible buffer at the end. Use the math: the sum of expected values is your aggressive target, and that sum plus two combined standard deviations is your roughly 95 percent committed date. The space between them is the buffer you can watch shrink and manage.

Keep two kinds of slack separate. Contingency reserve covers known risks and lives inside the plan. Management reserve covers the surprises nobody listed, sits above the plan, and is released only by a deliberate sponsor decision. Present the result as a range: “We expect day 40; we are committing to day 50 to absorb normal variability.” Now a slip is a conversation about the buffer, not a broken promise.

Plans are hypotheses; keep testing

The plan you make on day one is a guess about the future, and the future arrives daily. Track it with velocity and a burnup chart. Velocity, forecast as a range rather than a single average, converts remaining backlog into a finish window. A burnup chart, which plots completed work and total scope as separate lines, does something burndown cannot: it makes scope creep impossible to hide. When stakeholders keep adding work, the rising scope line is your most honest friend.

Then re-forecast every iteration. Recompute the end date from current reality and compare it to your commitment. If the gap is opening, you still have time to choose: cut scope, add capacity, extend the date, or spend buffer, each a deliberate trade-off. Finally, record actuals. The work you finish today becomes the reference class that makes tomorrow’s estimates better. That is the quiet secret of teams who seem to always hit their dates: they are not better guessers, they are better learners.