Software Project Estimation: Methods and Best Practices

Why software project estimation is hard

Software is built once, not manufactured repeatedly, so every project contains some unknowns: unclear requirements, integration surprises, changing priorities and technical challenges discovered along the way. Early estimates are therefore ranges, and they narrow as more is known. The goal is not a perfect number but a reliable range and a process for managing uncertainty.

The cone of uncertainty

Illustrative ranges; actual accuracy depends on the project and team.

This is why a short discovery phase before committing to a fixed price is so valuable.

Common estimation methods

Why estimates go wrong

• Requirements are incomplete or change without re-estimation
• Integration and data migration effort is underestimated
• Non-development work is forgotten: design, testing, deployment, meetings
• Optimism bias and pressure to give low numbers
• Unknown technical risks not investigated early

How to get estimates you can trust

• Invest in a short discovery phase before fixing price
• Ask for ranges with stated assumptions, not single numbers
• Include design, QA, project management and deployment explicitly
• Prototype or spike the riskiest parts early
• Re-estimate regularly and track actual versus estimate
• Agree how scope changes will be estimated and approved

Worked example: a three-point estimate

Suppose a feature is broken into four tasks. For each, the team gives an optimistic (O), most likely (M) and pessimistic (P) estimate in days. The PERT expected value is (O + 4M + P) ÷ 6.

Illustrative numbers for explanation only.

Notice that the total is higher than the sum of “most likely” values. The pessimistic cases — usually integrations and unknowns — pull the expected value up. This is a more honest number than the optimistic total that often ends up in proposals.

What a good estimate document includes

• Scope: features included and explicitly excluded
• Assumptions: integrations, data quality, availability of decision-makers
• Breakdown by phase or feature, including design, QA, project management and deployment
• A range rather than a single figure, with a confidence level
• Team composition and duration
• Key risks and how they will be handled
• How changes to scope will be estimated and approved

Hidden work that is often forgotten

As a rule of thumb, these activities can account for a substantial share of a project. If an estimate seems to cover only “coding”, ask where they are.

Tracking estimates during delivery

Estimation does not end when the project starts. Track completed work against the plan every sprint, update the forecast and raise risks early. A burn-up chart showing total scope and completed work makes it easy to see when scope is growing faster than progress. When the forecast moves, discuss options openly — reduce scope, extend the timeline or add capacity — rather than hoping the gap will close by itself.

Questions to ask about any estimate you receive

• What assumptions is this based on, and what happens if they are wrong?
• Does it include design, QA, project management and deployment?
• Who is the team, and how senior are they?
• Which parts carry the most uncertainty?
• How will changes in scope be priced?
• How will we see progress against the estimate?

Estimate ranges by stage of definition

A useful habit is to label every estimate with the stage it was produced at. A ballpark from a one-page brief should be presented as a wide range for budgeting only. An estimate after discovery, with user stories and designs, can be used for planning and contracts. Mixing the two — treating an early ballpark as a commitment — is one of the most common sources of conflict between clients and development teams.

Estimating with story points: a short example

Agile teams often estimate in story points, a relative measure of size and complexity. The team picks a small, well-understood item as a reference, say “add a field to a form” worth 1 point, and sizes everything else relative to it.

Illustrative example. Point values are only meaningful within one team.

After a few sprints, the team’s velocity, the average points completed per sprint, turns a points estimate into a time range. If a team usually completes 20–25 points per sprint, a 120-point release is roughly five to six sprints of work.

Estimating work you have never done before

Every project contains some unfamiliar work: an API nobody on the team has used, a new device, an unusual algorithm. Rather than guessing, reduce the unknown first:

1. Name the unknown

   Write down exactly what is uncertain. Is it the API’s limits, data quality or a performance target?

2. Time-box a spike1–5 days

   Spend a fixed, small amount of time building a throwaway prototype to learn the answer.

3. Re-estimate with what you learned

   Replace the guess with an estimate based on evidence, or flag the risk if it remains.

4. Keep a contingency for residual risk

   Add a visible buffer for the remaining uncertainty rather than hiding it in every task.

Contingency: how much buffer is reasonable?

Contingency is not padding. It is an explicit allowance for known uncertainty. A common rule of thumb is to scale it to how well defined the project is:

Rules of thumb only. The right buffer depends on the specific risks identified.

Keep contingency visible as its own line, and agree who can approve using it. That keeps conversations honest when it is needed.

Estimate review checklist

Before you rely on an estimate, internal or from a vendor, check it against this list:

• Every major feature from the scope appears in the breakdown
• Design, QA, project management, DevOps and deployment are included
• Data migration and integration effort is estimated separately
• Assumptions and exclusions are written down
• Risks are named, with contingency attached
• The estimate states its accuracy range and the stage it was made at
• Team composition and seniority match the effort assumed

If you are comparing several quotes, our RFP guide explains how to normalise them.

Glossary of estimation terms

Communicating estimates to stakeholders

An accurate estimate can still cause trouble if it is communicated badly. A few habits help:

• Always give a range and the confidence behind it, such as “10–14 weeks, likely 12”, never a single date from an early estimate.
• State what the range depends on: scope decisions, availability of people, third-party responses.
• Update the forecast every sprint and share it, including when it gets worse.
• Separate the estimate (what we think it will take) from the target (what the business wants) and the commitment (what we agree to deliver).

When to re-estimate

An estimate is a snapshot of what was known on the day it was made. Re-estimate rather than stretching the original numbers when:

• Scope changes by more than a small, agreed amount
• A spike or prototype reveals that a key assumption was wrong
• The team composition or availability changes
• A third-party dependency behaves differently than expected
• Actual progress drifts consistently from the forecast for two or more sprints

Worked example: from feature list to budget range

Imagine a hypothetical customer portal with login, profile management, order history, document downloads and support tickets. A simple estimate might be built like this:

Illustrative numbers only; your scope, team and integrations determine real figures.

The total of roughly 43–77 days becomes a budget range once multiplied by the team’s day rate, with the wide gap reflecting integration uncertainty. A short technical spike on the order system integration would narrow the range considerably.

Estimation anti-patterns to avoid

• Anchoring on a number someone said in the first meeting
• Asking one person to estimate work others will do
• Converting a range into its lowest value when presenting it
• Treating an estimate as a commitment before scope is agreed
• Never comparing actuals with estimates, so nobody learns

Using estimates to make decisions

An estimate is most useful as an input to choices: which features to build first, whether to phase a project, or whether a custom build is worth it compared with an existing product. Seen that way, a range is not a weakness but a tool for discussing risk. See also software development costs and custom vs off-the-shelf software.

Estimating maintenance alongside the build

Estimates often stop at launch, which hides a large part of the real cost. Add a line for the first year of support — monitoring, updates, fixes and small improvements — so stakeholders see the full picture when they approve the budget. A common rule of thumb is 15–20% of the build cost per year.

Fixed price or time and materials?

Fixed price works when scope is well defined after discovery; it moves risk to the vendor, who prices it in. Time and materials suits evolving products, with budget controlled through prioritisation and regular reporting. Many projects combine both: a fixed-price discovery, then sprints on time and materials. See software development costs or request an estimate.

Browse more practical guides in Software Development Guides & Resources.