How to Estimate Software Projects: Scope, Budget & Template

Setting budgets for software development

People need an indication of costs before starting a project, and rightly so. A useful software estimate connects a defined outcome to a work breakdown, effort ranges, rates and explicit assumptions. It also says what is excluded and when the numbers will be revisited.

This guide explains how to build that estimate before implementation, whether you are planning with your own team or comparing agencies. If you need help turning the scope into a first release, our product engineering service covers planning, delivery and ongoing improvement.

Start with an Estimation Brief

• Outcome and release boundary: who benefits, which workflow must work, and how you will accept it.

• Included work and exclusions: platforms, roles, integrations, data migration, testing, deployment and support.

• Assumptions: access to people and systems, available designs, expected data quality and team capacity.

• Constraints: budget boundary, required date and dependencies outside the delivery team's control.

• Unknowns and next checkpoint: what needs investigation, who owns it and when the forecast will be updated.

An estimate is a prediction based on the information available, not a fixed implementation plan. If new information changes the work, either change the scope, the budget or the schedule explicitly.

An established team can use its own delivery history to inform forecasts. A new project may first need a bounded discovery phase. When scope is still unclear, provide a broad scenario with low confidence rather than a precise total unsupported by evidence.

Rules of thumb for estimation

If you have something concrete enough to estimate, then following the points below you'll stand a fighting chance.

1. Figure out as much as possible about the scope within reason

Discuss with the stakeholders you have access to. Obviously you cannot achieve an exact specification. The only way to do that is to implement the whole project, then travel back in time giving yourself the outcomes. To avoid any time-space paradoxes just try to clarify everything possible within reason.

You will be constrained by time, access to stakeholders and certain things simply not being decided on yet. If there are known unknowns, then document them as known unknowns.

2. Make and state your assumptions.

Make uncertain parts concrete enough to estimate by stating an assumption and what happens if it is wrong. For example: assume the CRM has a documented API, credentials are available during the first week and no historical data cleanup is required. Assign an owner to verify those assumptions.

3. Split the work into estimable chunks

This can be e.g. user stories, but if many people are involved in a story then you may want to split it further into sub-tasks. If chunks end up being over 10 days of work, it likely contains a lot of uncertainties.

That may be ok depending on the detail wanted. Sometimes these are fuzzy things in the far off future and we're forced to do placeholder estimates to stipulate that "this will cost something".

4. Phase the work

The further away a phase is and the less its scope is understood, the less confidence you should place in its initial estimate. Keep the next release's estimate separate from later roadmap scenarios.

After each release or meaningful discovery, compare actual effort with the assumptions and update the remaining forecast. Do not silently overwrite the original estimate: keeping the change visible helps explain what was learned.

5. Include delivery and coordination work

Include environments, continuous delivery, release preparation, monitoring and handover as well as visible features. Account for design, testing and product coordination where they are needed.

Choose one convention for meetings, code review and routine coordination: include them within task estimates or allow for them separately. Document the convention so the same time is not added twice.

6. Try to think of all the common requirements for a certain task type

It's easy to forget common requirements which stakeholders don't think of mentioning explicitly, leading to consequential underestimation of work.

• For form inputs: Character limits, default values, input masks, validation messages, server side checks for duplicate username etc.

• Graceful user friendly error handling

• Mobile layouts / Responsive design

• Immediate user feedback on various actions

• Browser compatibility requirements

7. Let the people who are going to do the work do the estimation

Ask the people expected to do the work to estimate it. If the team is not yet known, use someone with relevant experience and record the assumed skills and availability. A change of team can change the estimate.

8. Document your chunks of work in a spreadsheet

Some PMs may feel the allure of putting things into their PM-tool (Jira, Asana or the likes) but I recommend sticking to spreadsheet in this phase still. This is to derive a budget, not to create a backlog for a project. The spreadsheet allows you to move rows around, adjust daily rates, dropping rows/features to see how certain parts affects your budget.

9. Estimate in work days

For an early budget, person-days are a useful unit because you can combine them with rates. Define what a person-day includes and avoid precision the scope cannot support. If an established team uses story points, use that team's observed delivery history when forecasting; do not apply a universal points-to-hours conversion.

10. Do many independent estimates

Independent estimates can expose assumptions that a group discussion misses.

Where the decision warrants the effort, have two or three people estimate separately using the same scope. Compare their reasoning before discussing a combined view. Do not force agreement merely to produce one attractive number.

11. Do three-point estimations

For uncertain tasks, ask for optimistic, most likely and pessimistic effort, together with the conditions behind each. The pessimistic value is a scenario, not a guaranteed maximum. Large spreads show where investigation may be more valuable than refining arithmetic.

One optional three-point approach is the PERT weighted estimate:

  Expected = (Optimistic + 4 * Nominal + Pessimistic) / 6

A common PERT spread approximation is:

  Approximate PERT spread = (Pessimistic - Optimistic) / 6

These formulas summarize judgment; they do not establish a measured probability of finishing on time. Shared risks, such as a single unreliable integration affecting many tasks, mean uncertainty cannot be reduced simply by adding task averages or treating all tasks as independent.

The worked example below shows how to keep an effort range visible when turning an estimate into a budget.

12. Before estimating, review the spreadsheet and chunks of work together with estimators

There should be discussion and adjustment of your chunks of work as estimators ask questions and assumptions are made. You may also split the work further or add new tasks. Write down any clarifications in the descriptions.

13. Be conservative in estimates when it comes to new tools

This includes new techniques, libraries, frameworks, architectures etc. People can be rather good at estimating when they're e.g. using familiar software architectures. Anything new is risky. If it can't be avoided then this should be reflected in the estimates. People tend to have optimistic views of new tools they read about online, but the picture is often not as rosy as they imagined once they start using them.

14. Be conservative in estimates when it comes to new integrations

If it's a well known public API it's usually easier to predict, but it can be risky integrating to internal services owned by other teams. They may not have an api, and/or they may not be incentivised to help your project. Fully booked calendars, long meetings, delays, are the norm in some organisations.

15. Quality is more work than we expect

State what release quality means. A prototype, controlled pilot and public product can have different requirements, but real-user releases still need appropriate access controls, recovery and testing. Include acceptance checks, supported devices, error states and operational readiness in the estimate.

16. Take into account work day overhead

Reviewing code, discussing decisions and supporting colleagues are work. Use the team's actual working pattern when estimating capacity rather than an unsupported universal percentage of time spent coding. Check that routine overhead has not also been added as a separate allowance.

17. Review estimates together, then discuss and re-estimate until you reach consensus.

When estimates differ, find the assumptions causing the difference and update the work description. Re-estimate after clarification. If uncertainty remains, show a range and an investigation step rather than forcing a false consensus.

Estimating is high pressure

It is natural to feel pressure when a budget or deadline depends on your estimate. Make confidence and assumptions visible. A transparent range with an early review point is more useful than a precise figure that everyone privately doubts.

Receiving feedback on your estimates

Your numbers will be questioned, and you should be able to explain them.

It's too expensive

Review the work breakdown rather than debating only the total. Identify the tasks and assumptions driving cost, explain why they are included and show the effect of removing or changing them.

Finding compromises

Sometimes the estimate can't arrive under a certain upper budget limit. Acknowledge stakeholders' concerns and offer them options.

• Remove or simplify lower-value capabilities.

• Phase the release so a smaller group of users can get value earlier.

• Change the implementation approach when it still meets acceptance criteria.

• Keep required security, accessibility and operational work visible rather than silently cutting it.

Give stakeholders control to adjust the scope.

Don't under-estimate to "win"

If expectations aren't aligned with reality and good enough compromises can't be made, then it's better to call off a project before it starts. Otherwise you're looking at a list of the following consequences: missed deadlines, money problems, broken trust, burn outs, low morale, poor quality, failed launch, loss of business and reputation.

Everyone loses. A good estimate should aim at project success.

Manage the Budget Without Spending It by Default

An estimate is a planning tool, not a target for consuming every allocated day. Review completed outcomes, actual cost and remaining work at agreed checkpoints.

If work finishes earlier than expected, return the unused budget or agree the next investment explicitly. If a forecast rises, expose the reason and the available scope choices before the budget is exhausted.

Turning this into a schedule

Effort and elapsed time are different. Thirty person-days do not automatically mean three weeks for two people: the work may have dependencies, specialist bottlenecks or periods waiting for feedback.

Team size matters

Identify which tasks can run in parallel and which must happen in sequence. Adding people also adds onboarding and coordination. Base a delivery forecast on the proposed team's actual capacity and the dependency path, not just total effort divided by headcount.

No one is present all the time

Use a calendar showing allocation, planned leave, other commitments and external review dates. State any allowance for unexpected absence and revisit it as the delivery date approaches.

Onboarding bears real costs

Plan access, environment setup, product context and knowledge transfer. Agree how personnel changes will be handled and how they affect cost and delivery.

For a first product release, our MVP timeline guide shows how to turn a narrow scope into milestones and explicit launch assumptions.

Worked Example: From Effort to Budget

The following is an illustrative calculation for a small web product release. It is not a Makers’ Den rate card or a quote. Assume a blended rate of €800 per person-day, with routine meetings and code reviews already included in the effort.

Labor cost is 27–45 days × €800 = €21,600–€36,000. If the team identifies an additional 3–5 days for a specific unresolved integration risk that is not already included in those ranges, the scenario becomes 30–50 days, or €24,000–€40,000.

Keep that risk allowance visible and avoid counting it twice. Add any hosting, licenses, third-party services and taxes separately where applicable. Explain whether post-launch support is included. The resulting range is a planning scenario, not a statistical confidence interval.

A Reusable Estimation Template

Use one row per work package. Include these columns: release or phase; outcome and acceptance criteria; owner or role; assumptions; dependencies; optimistic, likely and pessimistic effort; rate; cost range; unresolved risk; and next review date.

Maintain a short summary above the rows with the estimate's date, version, scope exclusions, confidence, expected team allocation and the decision it supports. When comparing agencies, ask each to state its assumptions in the same structure.

For an example estimation template, check out this Google sheet .

For a broader reference on work breakdowns, assumptions, risk analysis and updating costs, see the GAO Cost Estimating and Assessment Guide .

Keep the Estimate Useful After Kickoff

At each agreed checkpoint, report cost spent, the forecast cost to complete, total forecast and the reason for any change. Link changes to decisions or evidence: a revised integration, a new requirement, a simpler workflow or observed delivery pace.

Makers’ Den can help scope and deliver the next release through product engineering . If the work centers on a React application, see our ReactJS development service . Discuss your scope and budget with a Maker .