In short
Estimate software by decomposing a bounded outcome into complete workflows, data and business rules, integrations, quality requirements, migration, operations, and delivery work. State assumptions and exclusions, use ranges for uncertain areas, investigate the highest-risk items first, and update the forecast as discovery and implementation produce evidence.
Estimate the system, not the screens
For each workflow, include:
- entry and success;
- data and rules;
- permissions;
- loading, empty, validation, failure, and recovery;
- integrations;
- administration and support;
- analytics;
- testing and deployment.
A login screen may conceal identity provider, invitations, recovery, roles, sessions, audit, and security work.
Use an estimation sequence
- Define outcome, users, scope, and non-objectives.
- Map complete workflows.
- Model data, permissions, and integrations.
- State quality, security, performance, and operating requirements.
- Identify unknowns and dependencies.
- Break work into reviewable slices.
- Estimate with the people doing the work.
- Add explicit risk ranges—not hidden padding.
- Sequence high-risk evidence early.
- Reforecast after discovery and each major slice.
Separate confidence levels
| Confidence | Treatment |
|---|---|
| Known repeated work | Narrow range |
| Understood but unbuilt workflow | Moderate range |
| Unverified integration or data | Spike or wide range |
| Undefined product decision | Do not pretend to estimate; resolve first |
One total hides which assumption controls it.
Include non-feature work
- discovery and product decisions;
- design and content;
- architecture and environments;
- migration and data cleaning;
- accessibility and security;
- test automation and manual QA;
- monitoring, backups, and recovery;
- documentation, training, and handover;
- release and stabilisation;
- project and stakeholder coordination.
Estimate calendar separately from effort
Ten person-weeks do not automatically become two calendar weeks with five people. Shared architecture, review, dependencies, communication, and decision access limit parallel work.
Include client approvals, legal review, credentials, vendor response, and content as calendar dependencies.
Communicate the forecast
Provide:
- estimated range;
- included outcome and scope;
- assumptions and exclusions;
- highest uncertainty;
- dependencies;
- what could move cost or date;
- next point for re-estimation.
Precision should increase as uncertainty falls.
Common questions
Why are software estimates often wrong?
Because product rules, data, integrations, failures, and dependencies are incomplete when the estimate is made, and the uncertainty is hidden inside one number.
Is fixed-price software development bad?
No. It can fit bounded, well-understood work. The contract needs clear assumptions, acceptance, change handling, and responsibility for unknowns.
Should estimates include contingency?
Yes, but connect it to identified uncertainty and risk rather than an unexplained percentage. Investigate high-risk items to reduce it.
What is the best estimation unit?
Use the unit appropriate to the decision. Teams may estimate effort internally while communicating cost and calendar ranges externally.
When should an estimate be updated?
After discovery, technical spikes, scope decisions, completed slices, integration findings, or any changed assumption that materially affects the forecast.
