%20--%3e%3ccircle%20cx='20'%20cy='75'%20r='10'%20class='chart-color'/%3e%3ccircle%20cx='40'%20cy='50'%20r='10'%20class='chart-color'/%3e%3ccircle%20cx='65'%20cy='63'%20r='10'%20class='chart-color'/%3e%3ccircle%20cx='87'%20cy='35'%20r='10'%20class='chart-color'/%3e%3c/svg%3e)
Blog
Estimate Delivery in Product Development
The Quest to Estimate Delivery in Product Development
What’s more important: meeting the deadline or delivering value? Time to market or time to money?
Ideally, it’s both.
It’s tempting to look at a neat Gantt or burndown chart and assume the future will line up exactly as was drawn.
This is the ideal world, but in reality, software projects are full of curveballs.
The problem isn’t always inability, but rather mismatched expectations and unknowns. A Gantt chart might give managers a sense of control (“just drag this task a bit later, no problem.”), but work doesn't always start or finish exactly on time for numerous reasons.
Milestones can often turn into meetings where teams instead apologise for missing a deadline communicated as a fixed date.
When a date slips, fingers often start to point.
Agile attempts to solve these issues with velocity measures, story pointing, scrum poker, etc, but quite often these also fall into the same trap.
Reframing the conversation
Most experienced delivery leaders eventually come to the same conclusion, that estimation isn’t about maths, it’s about expectations.
In truth, an estimate is just a best guess about what might happen, not a guaranteed delivery date.
Estimates can help guide decisions, but they aren’t the goal in and of themselves.
Successful outcomes, business value, customer satisfaction are the goal.
It helps to define an estimate much like a weather forecast.
We are never told it WILL rain at 15:00 on Monday, but rather that there is a 75% chance of rain.
In this way, when you communicate in terms of exact dates instead of forecasts or ranges, people take that date as truth and it is likely to lead to unrealistic expectations.
The best laid plans cannot account for your team members taking off sick, or their train being cancelled. You cannot always know all of the technical issues you might face until the work is being undertaken. The core focus of agile also lends itself to scope changes given the user feedback as they use a product or new business needs emerge. No two developers are the same, and a two day task for one might be a three day task for another. Meetings, interruptions, etc. The list goes on and on.
The healthiest teams have a culture where bad news is shared quickly so adjustments can be made, rather than shooting the messenger.
Ranges
Given that we should expect the unexpected, the way we communicate delivery dates should convey that.
One option is to communicate in ranges and buffers.
Instead of saying “we’ll deliver on Tuesday,” a team might say “we plan to deliver in 5–8 days.” This framing communicates uncertainty and could invite discussion about the risks and help the business appreciate the uncertainty.
Confidence Buffers
Another option is to communicate confidence in estimates. "We plan to deliver in 5–8 days.” could be communicated as "We plan to deliver in 5–8 days, but are only 60% confident”.
A buffer could be baked into the range based on confidence. For example, a "1–3 days" range might be communicated as "1–5 days" with a confidence buffer baked in.
This buffer doesn't only need to account for risks or uncertainty, but also the inherent optimism in estimates.
We are all in this together
There is no silver bullet, but the true deadline should be clearly communicated as shared goals, not an immovable date in the calendar. Clear communication leads to realistic expectations and therefore less frustration.
Product estimation doesn't fail because developers are bad people, but because uncertainty is unavoidable and human nature leans toward optimism. Rigid Gantt charts or fixed-date milestones ignore the chaos of real projects.
Gantt charts, burndown, and velocity, still have their place in all of this, but by treating estimates as guides, and not gospel, by managing risk explicitly, and by being open and flexible, teams can plan more effectively and deliver on value instead of dates.
Now about probabilistic forecasting and Monte Carlo simulations...