Estimating in Uncertainty: How to Give Honest Estimates Without Losing Stakeholder Trust
Software estimation is one of the most persistently dysfunctional practices in engineering. The dysfunction has a familiar shape: stakeholders request a date, engineers provide a best guess, the best guess becomes a commitment, the commitment becomes a deadline, and the deadline is missed for reasons that were foreseeable but not incorporated into the original estimate. The stakeholders are frustrated, the engineers feel defensive, and the organization responds by asking for more detailed estimates next time — which produces more detailed guesses that are still wrong, just more expensive to generate.
The root cause is not bad estimation skill. It is a category error: treating software estimation as though it were manufacturing estimation, where the inputs are known quantities that can be reliably combined into a known output. Software development is a learning activity. The team's understanding of what needs to be built changes as they build it. The estimate made at the beginning of a project is based on a much less complete understanding of the work than the estimate made halfway through, which is why estimates made at the beginning are systematically wrong and estimates made midway through are typically more accurate.
Engineering leads who understand this dynamic can communicate about uncertainty in ways that are honest without being organizationally unworkable.
Range estimates are more useful than point estimates because they communicate where uncertainty is concentrated.
The Range Estimate Approach
The simplest practical improvement on point estimates is the range estimate. Instead of committing to 'six weeks', offer 'between five and nine weeks, with the range reflecting current uncertainty about the scope of the data migration component'. The range is honest — it reflects the actual state of the team's knowledge — and it communicates something useful: where the uncertainty is concentrated. A stakeholder who receives a range estimate has actionable information: they know that reducing the range requires resolving the specific uncertainty, which they may be able to help with (by clarifying requirements, providing access to production data for testing, or accepting a scope reduction that removes the uncertain component).
The resistance to range estimates from stakeholders is predictable and important to address directly. Most stakeholders experience range estimates as vagueness — as the engineer's way of avoiding commitment rather than providing useful information. The coaching response is to explain the range as a confidence interval: 'We are 80% confident the work will be completed within the five-to-nine week range. A six-week point estimate would be accurate about 30% of the time. Which number gives you more useful information for your planning?' Framed this way, the range estimate is clearly more useful — it gives the stakeholder the information they need to plan for scenarios on both ends of the range rather than being surprised when the point estimate is wrong.
Connecting estimates to learning milestones converts estimation from a one-time prediction into a running calibration
Connecting Estimation to Learning Milestones
A more sophisticated approach to estimation under uncertainty is to replace timeline commitments with learning milestone commitments. Rather than committing to a delivery date, the engineering lead commits to a series of questions the team will have answered by specific points in the project, and explains what each answer implies for the timeline. 'By the end of next sprint, we will have completed the data model investigation. If we find what we expect, the full timeline is six weeks. If we discover the migration complexity we are concerned about, the timeline is eight to ten weeks. We will have that answer for you in two weeks.' This approach connects the estimate to the team's actual learning process and gives stakeholders a specific point at which they will have better information.
This milestone-based approach maps naturally onto the Lean UX framework's emphasis on making assumptions explicit and testing the most dangerous ones first. The team's estimate uncertainty is concentrated in their untested assumptions. Testing those assumptions early — and making the test results explicit stakeholder communication milestones — converts estimation from a one-time prediction into a running calibration. Stakeholders who are included in the calibration process develop a more sophisticated understanding of how software estimates work, which reduces the gap between stakeholder expectations and engineering reality over time.
Building Estimation Credibility Over Time
The most effective long-term strategy for honest estimation is a track record. Engineering leads who consistently provide range estimates with clear uncertainty explanations, who communicate proactively when new information changes the range, and who retrospectively analyze their estimation accuracy with the team build a reputation for honest uncertainty management. This reputation is worth more than any individual accurate estimate, because it changes the stakeholder relationship from adversarial to collaborative.
Stakeholders who trust that an engineering lead will tell them the truth about uncertainty — including uncertainty that is uncomfortable to communicate — stop applying pressure for precision that the engineering lead cannot honestly provide. They start asking better questions: 'What would need to be true for the range to be five weeks rather than nine?' instead of 'Can you commit to six weeks?' The former question is a genuine collaboration on uncertainty reduction. The latter is a negotiation where honesty is penalized. Engineering leads who build trust through consistent honest communication eventually create the conditions where honest estimation is rewarded, which is the only sustainable environment for accurate forecasting.
The Bottom Line
Honest estimation is not a technical skill. It is a communication skill that requires understanding what stakeholders actually need (the information to plan under uncertainty, not a precision that does not exist), and providing it in a form that is useful rather than comfortable. Engineering leads who master this communication — range estimates, learning milestones, proactive uncertainty updates — build the credibility that makes them valuable strategic partners rather than delivery machinery. The goal is not to get better at predicting. It is to get better at being honest about what can and cannot be predicted, and to give stakeholders the tools to plan intelligently given that honest account.
Related Posts from Sense & Respond Learning
Moving from Dates to Deliverables: How to Build an Outcome-Based Roadmap
Technical Debt as a Product Problem: How to Make the Business Case for Refactoring
Managing the 'Shiny Object': How to Say No to Executives Using Outcome Data
The Engineering Lead's Guide to Running Effective Sprint Reviews
Further Reading & External Resources
Lean UX — Gothelf & Seiden (O'Reilly) — Framework for connecting estimation to assumption testing and learning milestones
The Mythical Man-Month — Frederick Brooks — Classic analysis of why software estimation fails and what can be done about it
NoEstimates — Vasco Duarte — A practical alternative to estimation-based planning using throughput data
Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.
Explore the full library at https://www.senseandrespond.co/blog
