Estimation Is Prediction Under Uncertainty

Software estimation is predicting how long a task will take when the full scope of work is not yet understood. Engineers consistently underestimate because software development involves iterative discovery — requirements are clarified, edge cases emerge, and dependencies are uncovered during implementation. At Nexis Limited, we use practical estimation techniques that acknowledge this uncertainty rather than pretending it does not exist.

Why Engineers Underestimate

  • Planning fallacy: Humans systematically underestimate time for future tasks, even when they have experienced similar overruns before.
  • Happy path thinking: Estimates often reflect the best-case scenario — no bugs, no requirement changes, no integration problems, no interruptions.
  • Scope invisibility: Tasks feel smaller from the outside. "Just add a login page" hides authentication, session management, password reset, email verification, rate limiting, and error handling.
  • Anchoring: Once a number is mentioned ("this should take about a week"), it becomes an anchor that biases subsequent estimates downward.

Estimation Techniques

T-Shirt Sizing

Classify tasks as XS, S, M, L, or XL rather than estimating hours. This is faster, reduces false precision, and encourages relative comparison. Map t-shirt sizes to time ranges for planning (XS: 1-2 hours, S: half a day, M: 1-2 days, L: 3-5 days, XL: needs decomposition).

Three-Point Estimation

Estimate three values for each task: optimistic (everything goes perfectly), most likely (normal conditions), and pessimistic (significant problems). The expected duration is roughly: (optimistic + 4 × most likely + pessimistic) / 6. This makes uncertainty explicit and produces more realistic timelines.

Historical Velocity

Track how much work the team actually completes per sprint. After several sprints, velocity stabilizes and provides a data-driven basis for planning. If the team consistently completes 30 story points per sprint, planning 35 is optimistic and planning 25 is conservative.

Buffer Strategies

  • Time buffers: Add 30-50% to raw engineering estimates for known unknowns (integration issues, testing, code review).
  • Scope buffers: Prioritize features as "must have," "should have," and "nice to have." Scope to deliver all "must haves" with time for most "should haves." Drop "nice to haves" if time runs short.
  • Iteration buffers: Reserve the last 20% of a project timeline for polish, bug fixing, and changes that emerge from user testing.

Communicating Estimates to Stakeholders

  • Provide ranges, not point estimates: "2-3 weeks" rather than "2 weeks."
  • State assumptions explicitly: "This estimate assumes the API documentation is accurate and the test environment is available."
  • Distinguish estimates from commitments — an estimate is a prediction, a commitment is a promise.
  • Update estimates as information emerges — the estimate at 50% completion is more accurate than the estimate at 0%.

Reducing Estimation Error

  • Break large tasks into smaller pieces — errors compound less with smaller estimates.
  • Use spike investigations for tasks with high uncertainty before estimating the full implementation.
  • Review past estimates against actuals — learn from overruns and apply the patterns.
  • Have multiple team members estimate independently to avoid groupthink and anchoring.

Conclusion

Software estimation will never be precise — it is a prediction about future work under uncertainty. Acknowledge this honestly, use techniques that make uncertainty explicit, add appropriate buffers, and communicate in ranges rather than false certainties. Teams that estimate honestly and communicate transparently earn more trust than teams that underestimate and miss deadlines.

Need help with project planning? Our team has experience planning and delivering complex software projects.