A software estimate is often requested before the team knows enough to give a confident answer.
The requirement may be incomplete. The affected parts of the system may be unclear. Another team may need to provide support. Yet someone still needs an estimate for planning.
Estimation has traditionally depended heavily on experienced developers. They carry context about the system, remember similar work, and know where surprises tend to appear. But that knowledge can be hard to share. Two people may give different estimates because they remember different projects or make different assumptions.
A single number can hide this uncertainty. A range, along with its assumptions and risks, gives the team a more honest starting point.
Estimate the uncertainty, not just the tasks
Consider a hypothetical example: a team plans to add a reporting feature to an existing application.
The visible work might include building a report and displaying it to users. But the estimate could change depending on questions such as:
- Is the required data available and reliable?
- Which users should be allowed to see the report?
- How much data will the report need to process?
- Will it need to update in real time?
- What testing, security review, or changes to existing systems are needed?
Until the team investigates these questions, a precise estimate may be misleading. A useful estimate shows a range and explains what could move the work toward either end.
Use a method that fits the evidence
Different estimation techniques suit different situations:
- Analogy compares the work with relevant past projects.
- T-shirt sizing gives an early sense of scale when detailed planning is premature.
- Three-point estimation considers optimistic, realistic, and pessimistic outcomes.
- Expert judgment brings in specialist knowledge when the work is unusual or data is limited.
- Parametric estimation applies a reliable measure or rate when one is available.
The technique should fit the evidence. A close comparison may make analogy useful. A major unknown may call for a wider range and further investigation.
No method removes uncertainty. The aim is to make the basis for an estimate clear enough that others can question and improve it.
Where AI can help
An AI estimation assistant can help structure the discussion. It can gather information about the requirement, scope, team, constraints, dependencies, and unknowns. If historical estimates and lessons are provided, it can use them to inform its recommendation — for example, by considering past accuracy, recurring risks, or which techniques worked well for similar tasks.
AI can also help break the work into areas the team can review and make assumptions and open questions visible. Its recommendations depend on the quality of the current information and available history. The team needs to check whether the suggested approach fits the work and the system.
Experienced developers remain essential. They validate technical assumptions, add context that may not be recorded, and challenge estimates that do not match what they know.
Treat the estimate as a forecast
A useful estimate should make clear:
- What work is included and excluded
- Which assumptions it depends on
- What risks or dependencies could change the effort
- How confident the team is, and why
- What information could narrow the range
As the team learns more, it should revisit the estimate. In the reporting example, investigating the data source might reveal that it is ready to use — or that it needs cleanup first. Either result could change the range.
After delivery, comparing estimated and actual effort can reveal useful patterns. Perhaps data preparation is often overlooked, or a familiar type of work is more predictable than expected. Recording why estimates differed helps the team improve future assumptions. The goal is shared learning, not scoring individuals.
From estimate to design
Estimation can inform design by surfacing likely scope, dependencies, and unknowns:
Requirement → Past learnings → Estimate → Design → Further reviews
The path is flexible. Design may reveal new work and prompt the team to update its estimate. An estimate is not a commitment that freezes the plan; it reflects what the team knows at that point.
A good estimate doesn’t promise exactly how long work will take. It helps the team explain what it knows, what it doesn’t, and what it should learn next.
Top comments (0)