“How long is it going to take?” asks the client or manager. They may need to plan a launch, approve a budget, or tell another team when work can begin. You may still be working out what the request involves.
A software time estimate gives them a basis for that decision. But it is easy for a rough estimate to become a deadline while the assumptions disappear.
The useful answer includes the work, the uncertainty, and the conditions that could change the date.
Revision note: The original article said to average task estimates and add 20–30% padding. That was incorrect for total effort. Add the task estimates, then explain the risks and schedule separately.
Break down the work before promising the date
Start with what “done” means. Does the request include testing, review, deployment, and support after release? Which decisions still need approval?
Then break the work into tasks that the people doing it can assess. For each task, describe a lower-effort and a higher-effort scenario. Record what makes the difference. A range without assumptions is just two guesses.
Consider this illustrative estimate for a small reporting change:
| Task | Lower effort | Higher effort | Assumption |
|---|---|---|---|
| Confirm the report fields | 2 hours | 4 hours | One business owner can approve the fields |
| Build the report | 4 hours | 8 hours | Existing data contains the required values |
| Test, review, and release | 3 hours | 6 hours | The existing release process can be used |
| Total effort | 9 hours | 18 hours | Scope remains as described |
Add the lower estimates together and the higher estimates together. Averaging them would describe a typical task, not the work required for the whole change.
This 9–18 hour range is a planning scenario, not a guaranteed limit or a statistical confidence interval. If the data is missing, the estimate needs to change. Several tasks may also depend on the same uncertain assumption, so their risks are not necessarily independent.
Effort is not a delivery date
Nine hours of work does not mean the report will be ready nine hours from now.
The business owner may be unavailable. A reviewer may have other commitments. The release may need to wait for a scheduled window. Some tasks can run together; others must wait for earlier work.
For one engineer with three hours available each day, 9–18 hours represents roughly three to six working days before additional waiting time. Adding another engineer does not automatically halve that schedule.
Present both the effort range and the delivery conditions. For example: “We estimate 9–18 hours of work. We can plan the release once the fields are approved and review time is reserved.” If the business needs a firm date, discuss which scope can change and which dependencies must be resolved first.
Make uncertainty visible instead of hiding it in padding
A fixed percentage cannot explain why a task might take longer. Include known work, such as meetings and testing, in the estimate. Name uncertain work separately.
If the main uncertainty is whether the data exists, inspect a sample before estimating the full report. A short investigation may be more useful than a wider guess. If uncertainty remains, agree on a contingency for the specific risk and say what would use it.
The estimate should reflect the people who will do the work, their availability, and their familiarity with the system. Review it with them rather than estimating everything as if you will do it yourself.
Update the estimate when the evidence changes
Keep the original assumptions with the estimate. When scope, availability, or technical knowledge changes, explain what changed and revise the remaining work.
After delivery, compare the estimate with the work that happened. Did you miss a task, wait for a decision, or discover a system constraint? That distinction tells you what to improve next time.
For a broader approach to scope and reusable capabilities, see LEGO Pieces and Feature Estimates.
Time estimating is a skill. As your responsibility grows from your own tasks to work across teams, the arithmetic remains simple. Making the assumptions visible is the harder part.
Happy coding!