How accurate can a software estimate be? The estimation range

01

Why is an early estimate a range and not a single figure?

Because at the start of a project, it is not the estimate that is uncertain, but the project itself: scope, edge cases, external systems, and acceptance are described but not yet verified. A single figure hides that uncertainty. A range with a lower and upper bound makes it visible and shows what still needs to be clarified.

Take a fictional example: the quality assurance team at a supplier has built itself a complaints tool, a convincing interface running on test data, and everyone was impressed at the demo. Now the tool needs to run in daily use, with real cases, connected to the inventory system, and management wants to know how much effort is still needed to get there.

Which questions an application must answer in production that nobody had to ask about the prototype is set out in the series From prototype to a production-ready application. Every one of those open questions is also a source of uncertainty in the estimate. As long as it stays open, a credible answer can only be a range, and the interesting question is how to narrow it.

02

What does the cone of uncertainty describe?

The cone of uncertainty describes how far estimates made by experienced estimators can be off at different points in a software project. The range is widest at the start and narrows with every milestone at which requirements, interface, and design get fixed. The cone shows the best case; things can always turn out worse.

Steve McConnell describes the model in a Construx paper from 2010. The horizontal axis lists typical milestones, from the initial idea through an agreed product definition, completed requirements, and a finished interface design, to finished software. The vertical axis shows the factor by which estimates can deviate at that point. According to McConnell, the cone narrows mostly within the first 20 to 30 percent of a project's timeline (Construx, 2010).

Two caveats belong with it. The cone shows the best achievable accuracy, since estimating worse is always possible and estimating better only happens by luck. And it does not narrow on its own: if a project is run in a way that leaves open points open, the uncertainty persists right through to the end. McConnell then speaks of a cloud rather than a cone (Construx, 2010).

03

Which milestones narrow the range?

The range narrows at milestones that answer an open question with a verifiable result. For a business application, those are written requirements, a clickable prototype that future users have actually operated, documented interfaces, and a built core workflow. Each of these steps ends with something demonstrable, not with a judgement call.

For the complaints tool, that means the demo shows the interface is understood. It does not show that the inventory system delivers the necessary order data, which edge cases arise with partial deliveries, or when a complaint counts as resolved. Exactly these points determine where the upper bound of the estimate sits.

04

How does the range change as evidence accumulates?

Each piece of evidence shifts both bounds closer to the baseline effort, and every further milestone shifts them again. Which missing piece of evidence would shrink the range the most is the most useful thing an estimate can tell you, because it names the next step of work. The calculator works this through with adjustable example figures.

Choose the phase the project is in, tick off what has already been established, and set a baseline effort. Watch which ticks shorten the bar and which gap the calculator reports as the largest open one. The complaints tool comes preset with example values: clickable prototype tested, users have operated it, baseline effort of 80 person-days.

With these example values, the range runs from 61 to 118 person-days, so the upper bound sits at almost double the lower one, and the largest open gap is undocumented interfaces. Set the phase to idea and remove every tick, and the range grows to 32 to 240 person-days. Once the core workflow is built and all four pieces of evidence are ticked, it narrows to 76 to 85.

05

How should you read low, expected, and high?

The lower bound describes the effort if the open points turn out to be simple, the upper bound the effort if they turn out to be difficult. The expected value usually sits closer to the lower bound, because it weights the most likely case more heavily. Passing on only that figure hides how far away the upper bound really is.

The calculator computes the expected value as a three-point estimate: low plus four times likely plus high, divided by six. The baseline effort serves as the likely value. The formula is widely used because it weights the most probable case more heavily while still accounting for both bounds.

The asymmetry is notable: the upper bound sits further from the baseline effort than the lower one does. A forgotten edge case, an interface that delivers different data than expected, or an extra round of alignment all add work. A planned task turning out to be unnecessary happens too, but less often on the same scale.

06

Which pieces of evidence shrink the range the most?

The strongest effect comes from evidence that resolves a question outside the team's own control: tested connections to external systems, and users who have actually operated the workflow. A stable data model and written acceptance criteria follow after that. The checklist helps you work out which pieces of evidence your project already has and which are still missing.

Which piece of evidence has the biggest effect depends on the project. An application with no external systems gains more from user testing, one with five connections gains more from tested interfaces. That is why the calculator names the largest open gap instead of prescribing a fixed order.

07

When is a fixed commitment justified?

A fixed commitment is justified once the range is small enough that its upper bound stays acceptable to everyone involved. McConnell advises against making commitments until the cone has narrowed. In practice that means the core workflow has been operated, interfaces are tested, acceptance criteria are in writing, and the remaining assumptions are stated in the proposal.

An early commitment is tempting because it promises planning certainty. But it only shifts the uncertainty elsewhere: if the actual effort lands near the upper bound, the project gets cut back, renegotiated, or quality suffers. McConnell notes that organisations should avoid commitments until the cone has narrowed, because before that point they simply do not hold up (Construx, 2010).

08

Which assumptions about estimates do not hold up?

Four assumptions come up especially often in conversations about effort: that more time makes an estimate more accurate, that a flat markup covers the uncertainty, that the lowest figure is the most accurate one, and that iterative projects can do without estimating. All four can be checked against the mechanism of the cone.

09

How do you compare estimates from different providers?

Compare the foundations first and the figures only after that: what state the project was in when the estimate was made, which assumptions are stated, what belongs to the scope, and which gap should be clarified next. Two figures based on a different state or a different scope cannot be meaningfully set against each other.

If an existing prototype is going to be developed further, its condition belongs in the foundation of any estimate. Recognising technical debt in AI-generated code describes the shortcuts in code that make every change more expensive. Which documents the handover into operations needs is covered in From proof of concept to routine operation.

iiterate Technologies GmbH, based in Adenau, develops custom software and AI applications, from architecture through implementation to operations, and hands over with source code and documentation. To talk through the state of your own project: contact.