Blog
Key takeaways:
Most writing on software project estimation is a list of techniques. You get expert judgment, analogous, parametric, three-point and planning poker, each with a sentence, and then nothing about what happens to the number afterward.
The techniques are the easy part. What decides whether software project estimation is useful is the process around it: which method fits your situation, who produces the number and who is allowed to challenge it, what gets written down alongside it, and what you do when someone with more authority says it is too high.
This guide covers that process. Converting three numbers into a confidence interval is a different skill from deciding who produces them, and that arithmetic is worked through in estimating software development time. The money question belongs to our breakdown of software development costs, and neither is repeated here.
Project estimation in software engineering is the practice of predicting the effort, duration or size of work that has not been done yet, together with the assumptions that prediction depends on. The second half of that sentence is the part most definitions drop, and it is the part that makes an estimate usable.
An estimate is not a commitment. It is an input to one. The commitment is a separate decision, made by whoever carries the consequence of missing it, and it can reasonably be a different number from the estimate as long as everyone knows which is which.
How well a project can be estimated also varies more than teams allow for. The characteristics that make a project straightforward to scope are the same ones that make it straightforward to estimate, which is the same property observed twice rather than a coincidence.
Estimation in software project management also has a job beyond the number. Two engineers sizing the same work differently have found a disagreement about what the work is, and surfacing that is often worth more than the figure either of them produced.
There is no best method, and anyone who tells you otherwise is selling one. Software project estimation is instead a question of fit between the method, the information you have, and whether you hold historical data from your own organization.
| Method | Use when | What it needs | Where it breaks |
|---|---|---|---|
| Expert judgment | Experienced people have done similar work | Access to those people, and independence between them | Invisible reasoning, hard to review or hand over |
| Analogous | A genuinely comparable past project exists | Records of what that project actually took | Comparability is usually assumed rather than tested |
| Function points | Scope is defined and you need an auditable size | A trained counter and a calibrated delivery rate | Measures size, not effort, until calibrated |
| Parametric models | You have organizational data to calibrate against | Historical data in the model's shape | Published defaults rarely fit your organization |
| Story points and velocity | A stable team with delivery history | Several iterations of actual throughput | Meaningless across teams or before history exists |
The analogous row is the one most often used badly. Comparability gets assumed from a surface resemblance rather than tested, and two projects that share a label can differ by an order of magnitude underneath it.
A marketplace is the standard example. Two of them can look alike and differ entirely in whether payments, disputes, payouts and supply-side onboarding are in scope, which is most of the work; building a marketplace is a category where the name hides more than it reveals.
Before reusing a past project as an anchor, list what was in its scope and what is in this one, side by side. If you cannot produce both lists, you are estimating from impression and calling it analogy.
Function points deserve a note because they are the most misunderstood row. ISO/IEC 20926:2009 specifies the definitions, rules and steps for the IFPUG functional size measurement method, and the standard is careful about what the output is: a measure of functional size.
Turning that size into hours is a separate step. The standard's own framing is that function point analysts have identified different delivery rates, meaning hours to deliver a function point, calibrated for varying functional domains, project sizes and complexities. A size measurement borrowed with somebody else's delivery rate is not an estimate of your project.
The honest decision rule is therefore about data rather than sophistication. If you have records of what your own work has taken, the formal methods become genuinely useful. If you do not, they produce precision you have not earned.
This is the most consequential position in the estimation literature and the one least reflected in practice. In a 2007 systematic review published in IEEE Transactions on Software Engineering, Magne Jorgensen and Martin Shepperd identified 304 estimation papers across 76 journals and classified each by research topic, estimation approach, research approach, study context and data set.
Their conclusion, rather than any single measurement in the review, is the part worth carrying. They report that the performance of more formal techniques has been erratic and has not documented higher accuracy than expert judgment, while expert judgment remains by far the most commonly used approach in industry.
The recommendations follow from the gap between what the field studies and what practitioners use. The review asks for more research on the estimation methods industry actually relies on, more studies run in real-life settings, and fewer studies that evaluate methods against arbitrarily chosen data sets.
That is not an argument for guessing. It is an argument against buying a model and expecting it to do the work, and it moves the attention to where the available gains sit: using more than one independent source, calibrating to your own history, and documenting what the number assumed.
Three roles need separating, and in most organizations at least two of them are held by the same person, which is where estimates lose their credibility.
The people who will do the work produce the estimate. That is not a courtesy, it is a quality measure, and it works best when they estimate independently before discussing. Combining independent estimates from different people, and preferably different approaches, is one of the better-supported findings in the literature.
Someone who did not produce the number reviews it. A reviewer's job is not to approve, it is to find the assumption nobody stated and to ask which single condition failing would halve or double the number. That role can rotate, and it should not sit with the person who wants the project approved.
Whoever carries the deadline signs it. That person decides what to commit to given the estimate and the risk, and owning that decision explicitly is what stops a commitment from being retroactively described as an engineering estimate when it slips.
Here is the artifact. An estimate is a number plus the conditions under which it holds, and the conditions are what let you revise it honestly later instead of arguing about whether anyone was wrong.
| Field | What to record |
|---|---|
| Scope version | The exact brief or requirements version being estimated |
| Method and calibration | Which method, and whether it is calibrated to your own historical data |
| Activities covered | Precisely which activities the number includes: design, build, test, deployment, documentation |
| Validity range | The size of work the method was calibrated for, since models misbehave outside it |
| Assumptions | Each one stated separately, so it can be reviewed and tested |
| Risks | What could go wrong, with an indication of likelihood and impact |
| Who estimated, who reviewed | Names, so the review actually happened |
| Calendar basis | Holidays, vacations and anything else that makes a week shorter than five days |
| Actuals at close | What it took, recorded against what was predicted |
Keeping assumptions formally is what allows a team to review them and run a simple sensitivity check, which is the practical reason to bother. If an assumption turns out false, you can say which part of the estimate moved and by how much, rather than re-estimating from scratch and losing the audit trail.
The last field is the one teams abandon. Closing it out means going back after release, where the work nobody estimated tends to surface, and treating what users do after launch as evidence rather than as a surprise.
The register also changes the conversation when something slips. An assumption that failed is a fact about the project; a missed estimate without a register is a judgment about a person.
A commitment is the estimate plus a decision about how much risk to absorb and who absorbs it. The gap between them is where contracts live.
The assumptions in the register are candidates for contract terms. If the estimate assumed the client supplies test data within five working days, that belongs in the agreement, because an assumption that only one side knows about is not an assumption, it is an expectation waiting to fail.
None of this works unless the scope underneath is specified tightly enough to test, which is the job a product requirements document does and the reason the two documents are written in that order.
The structural trap is fixing too many variables at once. Scope, date, budget and team size cannot all be fixed, and when someone tries, the variable that actually gives is quality, because it is the only one nobody is measuring that week.
Quality is not on the list anybody agreed, which is exactly why it moves.
So state explicitly which one is flexible. A project with a hard regulatory date and a flexible scope is manageable. A project where scope, date and budget are all fixed is not an estimate problem, it is a commitment that has not been costed.
If that is the position you are in, contact us before the first sprint rather than after the third.
Estimation only improves with feedback, and most teams never close the loop. Recording what work actually took, against what was predicted, is the cheapest accuracy improvement available, and it is the one organizations skip because the project is over and everyone has moved on.
Record it per work item rather than per project, because a project-level variance tells you nothing actionable while an item-level one tells you which kinds of work you systematically underestimate. Integration work and anything touching a third party are the usual culprits.
The same record at two granularities, and only one of them can be acted on.
The estimation literature has standard measures for this. The share of estimates falling within 25 percent of actuals is a commonly used one, and it is more informative than an average error, because a handful of catastrophic misses drags an average upward until it describes neither the typical estimate nor the bad one.
At VAULT the lesson is easiest to see where the scope moved. ProduceDesk came to us after shelving a first version it had built itself, and the service then pivoted early from moving distressed produce only to handling orders across every type of produce.
That pivot is the whole estimating story. The total was never the interesting number, because the thing being estimated changed shape; what a post-project record has to capture is which categories of work moved and why, since only that changes how the next estimate gets built.
Every estimator eventually hands over a number and is told it is too high. What happens next determines whether estimating in your organization means anything at all.
There are exactly two honest responses. Reduce the scope, which changes the work and therefore the number. Or accept more risk, which keeps the scope and lowers the confidence, stated explicitly. Changing the number while keeping the scope and claiming the same confidence is not a third option, because nothing about the work has changed to justify it.
The third branch is drawn the same size as the other two on purpose.
Practitioners describe the failure mode vividly. In a Reddit thread on handling imposed deadlines, an engineer described a team presenting a plan and timeline, management returning an adjusted timeline not based on it, announcing that publicly, and the first delivery being nowhere near ready three months later. That is anecdotal, and the advice in the replies is sound: the real levers are cutting scope or missing the date, and everything else should be escalated in writing.
One distinction from that thread is worth carrying into any such conversation. Hard deadlines exist, usually regulatory or contractual, and soft deadlines are frequently presented as hard. Asking which one you are looking at is a reasonable question, and the answer changes what you should be willing to trade.
The register is what makes this a professional exchange rather than a negotiation about optimism. You are not defending a number, you are showing which assumption would have to change for the number to come down, and inviting a decision about that assumption.
Estimating software projects well is less about technique than about the three habits around it: more than one independent estimate, a written record of what the number assumed, and a comparison against actuals once the work is done.
Start with the register even if you keep estimating exactly as you do now. It costs an hour per project, and it is what turns software project estimation from a recurring guess into evidence you can improve on.
Estimates that are routinely overridden and routinely missed usually point at a scoping and sequencing problem rather than an estimating one. We run our own engagements the same way this guide describes, settling scope and sequence in product strategy first, because an estimate is only as firm as the thing it is counting.
It is predicting the size, effort or duration of work that has not been done, together with the assumptions the prediction depends on. The assumptions matter as much as the number, because they are what let you revise it when something changes.
It is also distinct from committing to a date. An estimate is an input to that decision rather than the decision itself.
In project management the term usually covers the whole process rather than the calculation: deciding which method fits, having the right people produce the number, reviewing it, recording what it assumed, and tracking the result afterward.
That process is what makes estimates comparable over time. A number produced a different way each quarter cannot tell you whether you are getting better.
Pick a method that matches the information you actually have, get independent estimates from the people who will do the work, and write down what each one assumed. Combining independent estimates is one of the better-supported practices in the research.
For the arithmetic of converting three-point estimates into a range and a confidence level, our dedicated guide to estimating development time has the worked method.
Cost estimation converts effort into money, which adds rates, team composition, overheads and a run cost after launch. The effort estimate comes first and the money follows from it.
The conversion is where most of the variance enters, since the same effort can carry very different costs depending on who does the work. Our breakdown of software development costs covers that half.
Someone who did not produce it and does not benefit from it being low. The reviewer's job is to surface unstated assumptions and press on the one most likely to be wrong.
Keeping that role separate from the person seeking approval is the single structural change that most improves estimate quality, and it costs nothing. How you organize that depends on your development methodology, but the separation matters more than the ceremony.
If your estimates keep being overridden or keep missing, the cause is usually upstream of the arithmetic. Contact us and we will look at how they are produced, reviewed and used, and tell you which of the three is costing you the most.
