Estimation Is Not One Thing

When a team’s shorthand for uncertainty becomes the business’s shorthand for certainty

A team sizes a backlog item at five points on a Tuesday afternoon. Four developers, a brief disagreement about whether the third-party integration makes it a three or a five, a shrug, a five.

Nobody in the room means anything more by that number than: this feels roughly medium-sized compared with the other things we know.

Eight months later, that same five is sitting in a steering committee slide, converted into a date, and the date has become a promise to a customer.

Nobody lied to get it there. The delivery lead turned points into days because somebody needed a forecast. The programme office turned the forecast into a milestone because the roadmap needed one. The account manager repeated the milestone to the customer because that is what milestones are for.

At no single step did anyone make an obviously absurd decision. And yet a number that originally meant “roughly this big” now carries a contractual consequence. When it turns out to be wrong, the conversation will probably be about the team’s estimating discipline rather than about the translations the number silently underwent on its journey through the organization.

That is the estimation problem worth discussing.

Not whether estimates are good or bad, whether story points work, whether #NoEstimates was right, or whether agile teams should provide dates. The deeper problem is that “estimation” is not one activity, while organizations routinely behave as though it were.

“Can you estimate this?” is an incomplete question

When somebody asks, “Can you estimate this?”, an important part of the question is still missing:

What are they actually trying to find out?

They might mean:

• How large or difficult does the team think this piece of work is?
• How uncertain is it?
• Is it bigger or smaller than something else?
• How much might fit into the next iteration?
• When might this feature be finished?
• How much might the initiative cost?
• Can another team plan around us?
• Should we fund this?
• Can we promise something to a customer?
• Is our delivery system becoming more predictable?

These are not different phrasings of the same question. They concern different quantities, different time horizons, different information, different consequences of being wrong, and different decisions.

A rough comparison between two backlog items can be wrong without much consequence. A customer commitment can cost money, trust, or a contract when it is wrong. The fact that both happen to involve numbers does not make them the same activity.

Before deciding how to estimate anything, the organization therefore needs to ask:

What decision are we actually trying to make?

The hidden dimensions of an estimate

Once the decision is clear, several other questions follow.

What are we assessing? Effort? Complexity? Cost? Delivery time? Risk? Probability of hitting a date?

Whose knowledge matters? Technical implementation knowledge may sit with developers. Scope and business constraints may sit with product. Operational limitations may sit elsewhere. Historical delivery data may expose patterns no individual can intuit.

The useful question is not “Who owns the estimate?” but:

Whose knowledge must be present for this particular uncertainty to be assessed?

Timing matters too. The moment at which the organization most wants certainty is often the moment at which it knows the least: investment decisions happen before implementation; roadmaps are shaped before discovery; sales conversations happen before technical exploration.

That is not incompetence. It is a structural characteristic of uncertain work. Understanding accumulates as work proceeds.

So early information must be treated differently from later information. A coarse assessment made before discovery may be perfectly useful for deciding whether something deserves further investigation. It becomes dangerous only when nobody remembers what kind of information it originally was.

And finally: What happens if we are wrong?

A reversible €5,000 decision and a €10 million multi-year commitment should not demand the same level of analysis. High stakes do not magically make the underlying work more predictable. They increase the need to understand and manage the uncertainty.

Five words we routinely collapse into one

A large part of the problem becomes easier to see if we distinguish five concepts that organizations often use almost interchangeably.

An estimate is an assessment of an unknown quantity based on incomplete information.

A forecast is an estimate specifically about a future outcome: what is likely to happen given current evidence and assumptions.

A target describes what we want to happen.

A plan describes what we currently intend to do.

A commitment creates an obligation somebody else may legitimately rely on.

All forecasts involve estimation, but not all estimates are forecasts. More importantly, targets, plans and commitments are not merely “more certain estimates.” They are different kinds of statements.

A business can have a forecast saying:

There is a 70% chance of delivery by September 30.

and still decide to make the commitment:

We will deliver by September 30.

The remaining 30% uncertainty has not disappeared. The organization has made a business decision to accept it, perhaps because the opportunity is valuable enough, the consequences manageable enough, or contingency options exist.

A commitment is therefore not a prediction. It is a decision about risk made using a prediction.

This gives us a useful diagnostic question:

Is this number assessing something unknown, predicting reality, prescribing a desired outcome, describing intended action, or creating an obligation?

If we cannot answer that, we should probably not put the number into a roadmap yet.

Silent Reassignment

The most damaging pattern is not that organizations ask for estimates. It is that estimates are silently reassigned.

A measurement or assessment created for one purpose gradually starts doing another job without anyone explicitly deciding that its meaning has changed.

A team adopts story points as a local relative-sizing mechanism. Later somebody asks for a delivery date. Points are divided by historical velocity. The resulting forecast enters a roadmap. The roadmap becomes a target. The target becomes a commitment. The commitment is measured.

Eventually somebody asks why the team failed to meet its estimates.

Nothing malicious happened. The instrument was simply promoted through the organization one reasonable-looking step at a time.

That is Silent Reassignment.

Once the purpose of the number changes, the behaviour around the number changes too. If estimation accuracy becomes a performance measure, people learn to produce safer estimates. If high velocity is rewarded, points become easier to inflate. If every estimate is treated as the opening bid in a negotiation, people learn to add negotiation margin before the discussion starts.

And if dates become commitments the moment they are spoken aloud, uncertainty does not disappear from the work. It disappears from the conversation.

This is where Goodhart’s Law becomes relevant: once a useful signal becomes a target, people begin managing the signal itself. The organization may become better at appearing predictable while becoming worse at actually seeing its uncertainty.

The illusion of precision

Silent Reassignment also strips uncertainty from the artefact while leaving it untouched in reality.

Imagine a backlog containing 200 story points and a team that has recently completed around 20 points per sprint. The arithmetic says ten sprints. The spreadsheet says twenty weeks. The roadmap says Q3.

But the calculation quietly assumes that the backlog remains stable, the team remains stable, the nature of the work remains comparable, dependencies behave as expected, and the meaning of the points does not drift.

The arithmetic may be correct. The conclusion can still be unjustified.

A point estimate also looks more informative than it often is. Compare:

Delivery: September 28.

with:

50% probability by September 28, 80% by October 4, 95% by October 29.

The second answer looks less decisive but contains substantially more decision-relevant information. Leadership can now choose where on that risk curve it wants to make a commitment.

This is the difference between precision, confidence and risk tolerance. A precise-looking date is not necessarily a confident prediction.

Leadership still needs answers

None of this means leadership should stop asking about the future. Quite the opposite.

Somebody must decide where to invest and what not to fund. Somebody must judge whether a deadline is plausible, coordinate dependencies, determine whether a portfolio is overloaded, decide whether another team would actually help, and decide what can responsibly be promised externally.

“We cannot know” is not adequate decision support. The better response is:

What information do we actually need to make this decision, and what mechanism can credibly produce it?

Different decisions may legitimately require different mechanisms. Local comparison may need nothing more sophisticated than relative sizing. A delivery forecast may be better informed by throughput or cycle-time distributions and probabilistic forecasting. A financial decision may need cost ranges and comparable historical cases.

A customer commitment may require a forecast combined with explicit risk appetite, contingency, scope flexibility and contractual judgment. Operational metrics such as cycle time, throughput, WIP or work-item age can help us observe the delivery system without pretending that they are objective scores for team performance.

The point is not to establish a new universal estimation recipe. It is to stop asking one instrument to answer every organizational question.

Is the estimate worth what it costs?

Estimation itself has a cost. Time spent decomposing, discussing, modelling and recalculating is time and attention not spent elsewhere.

So the right question is rarely:

How accurately can we estimate this?

It is:

How much confidence do we need to make this decision responsibly, and what is it worth spending to obtain that confidence?

Sometimes more analysis is justified. Sometimes a short technical spike is cheaper than carrying a major unknown into a commitment. Sometimes historical evidence is good enough and further estimation adds little.

And sometimes the smartest move is to change the decision rather than improve the estimate.

Instead of asking:

Can we accurately estimate this €10 million programme?

ask:

Can we invest €250,000 to learn whether spending the next €9.75 million is sensible?

That changes estimation from an exercise in manufacturing certainty into an exercise in buying useful information.

Make the work easier to predict

There is a limit to what better estimation can achieve. Some delivery systems are simply harder to predict than others.

A large initiative with many dependencies, large batches of work and long feedback loops contains more opportunities for assumptions to fail and new information to arrive late. No estimation technique removes that. A more sophisticated forecast may represent the uncertainty better, but the uncertainty is still there.

So improving the forecast is only one option. Another is to change the conditions under which the work happens.

Reduce batch sizes and cross-team dependencies. Shorten feedback loops. Create clearer modular boundaries. Limit work in progress. Separate discovery uncertainty from delivery uncertainty. Stage investments, prefer reversible decisions, and make commitments smaller.

The effect is not merely that estimates become easier. Less depends on any individual estimate being right. Smaller pieces of work expose new information sooner, shorter feedback loops allow earlier correction, and smaller commitments reduce the consequences when reality differs from the forecast.

That changes the problem. Instead of asking ever more sophisticated methods to predict a large and uncertain undertaking, we can reduce the size and duration of the uncertainty we are asking them to predict.

Sometimes the best way to improve a forecast is therefore not to improve the forecasting method. It is to make the work easier to predict - and make being wrong less consequential.

The next time somebody asks, “Can you estimate this?”

Before answering with a number, ask:

1. What decision are we trying to make?
2. What exactly are we trying to estimate or forecast?
3. Do we need an estimate, forecast, target, plan or commitment?
4. Who currently possesses the relevant information?
5. What is still unknown?
6. What assumptions are we making?
7. How much confidence does this decision require?
8. When does the decision actually need to be made?
9. What happens if our prediction is wrong?
10. What method is proportionate to that purpose?
11. How will this information be used once it leaves this room?
12. Will using it that way change the behaviour of the people producing it?

Those questions do not make estimation simpler. They reveal that “Can you estimate this?” was never a complete question in the first place.

Go back to the five points from Tuesday afternoon.

The team was not necessarily wrong. Neither were the delivery lead, the programme office, or the account manager.

The failure happened in the spaces between them: every time information created to answer one question silently became the answer to another.

The real subject, then, is not estimation techniques. It is how organizations turn uncertain information about software delivery into decisions - and what happens when observation, prediction, intention, obligation and evaluation are allowed to blur into one another.

There is no single problem called estimation. There are different decisions requiring different information.

Until an organization makes those differences explicit, every argument about whether estimates are accurate, agile, useful or wasteful risks being two people arguing about different things while using the same word.

The team may have been completely right about the five.

Nobody was ever right about what the five would be asked to become.