Delivering features on time is overrated
Delivering features on time is overrated
The obsession with trying to meet timelines based on estimates made beforehand is silly
As a Product Owner, you get these kinds of questions every day:
“When can I expect my feature to be live?”
“Why does the timeline of the feature keep on slipping? Shouldn’t we know what we’re doing by now?”
“Why can’t you tell me the exact day the feature will be released to customers? How can I manage our marketing campaigns if I can’t give them a specific date?”
For Product Owners, a lot of valuable time is spent discussing timelines with stakeholders. Everybody wants to know when their precious feature is finished. When one of your features inevitably gets delayed, conversations may take a sour turn.
Is this obsessive focus on timelines warranted? Is it even possible to always deliver on time? Does delivering features on time even matter?
Before I start answering these questions, let me explain why features get delayed.
Why do features get delayed?
An estimate is an approximation of how long it takes to deliver a feature based on the best information available at the time. In software development, the “best information available” is usually pretty meager, because we are doing complex work where more is unknown than known.
Estimating software delivery timing is like trying to predict the weather more than ten days in advance: you will probably be wrong. You are invariably wrong because the amount of uncertainty is simply so high that you lack the information to make accurate predictions.
There are three types of uncertainty you always face when building any new feature:
Purpose uncertainty. Why are we making this feature? What’s the problem it should solve? The customer doesn’t have a perfect understanding of what they want, and we also don’t have complete knowledge of the customer.
End uncertainty. What do we need to build? How exactly should it work? We rarely know exactly how it must work upfront, and we are not able to describe it exhaustively for all situations that need to be supported.
Means uncertainty. How can we build it? How can we pull it off from a technical perspective? Getting something to work with code is less like following a recipe, but rather more like coming up with your own recipe for a tasty apple pie.
Estimates provided before you start doing the work are called a priori estimates. At this moment in time, the amount of uncertainty is highest, even if your preparation is excellent. Beforehand you are limited to the knowledge you can have before you start working on something.
Only by doing the work and learning, can you gradually reduce these sources of uncertainty and gain enough understanding to be able to forecast timelines accurately.
There is one problem: uncertainty gradually disappears only after you start working on that feature. The imprecise a priori estimate is already known and communicated to the customer, setting expectations. To make matters worse, these estimates are often locked from changes, putting you in a tight spot from the start.
What happens when features are delayed?
I had to deliver a complicated feature with fixed scope and a fixed timeline. Not a great situation to be in, I know. I hadn’t promised the scope or timelines, yet it was my job to make sure we would deliver as expected.
Somebody without intimate, technical knowledge and responsibility in execution promised a timeline of 2 months based on a single paragraph that was written down. Rolling the dice would be an apt description of the said estimate.
I told our customer upfront that we would never be able to meet the scope and timeline that was promised. It wouldn’t take 2 months, it would probably take at least 10 months. Maybe even longer. The customer was furious, especially since they paid a custom development fee to get this feature.
The ‘only’ thing we did wrong is giving an inaccurate estimate. But boy, can a wrong estimate be an incessant source of annoyance. In this particular case, the customer kept badgering me with our fairy tale timelines for many months.
How different would the world be if we could estimate perfectly?
Let’s imagine an alternative universe where our company would have perfect estimation capabilities. Impossible, I know, but let’s assume it would be possible. How would things have panned out differently for this delayed software project?
With our impeccable estimation capabilities, two things would have happened: 1. The custom development fee would have quintupled for our customer and 2. The customer would have received the feature precisely at the same time as before.
So in effect, the customer would receive the same feature at the same time for five times the price. Yet the customer would have been probably far happier because we met their initial expectations.
Delivering a feature still takes the same amount of time, regardless of your estimate. It is our expectations on timelines that create a perception of late delivery.
Software development is all about dealing with uncertainty and complexity. Estimates are made before you start working on a feature. This means the uncertainty will be highest, and understanding of complexity will be the lowest. In other words, when your estimates are correct, you got lucky.
That’s why I believe that delivering features on time is overrated. It just means you rolled the dice and hit the right number. My one-year-old daughter can do that too!
No amount of preparation can make your estimates accurate. It can make them more reliable but not accurate enough to be able to forecast timelines with a high degree of certainty. What you can’t and don’t know before you start doing the work will always find a way to blow up your estimates. As expressed in Hofstadter’s law:
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
I hope to have convinced you a priori estimation will always result in wrong estimates. What should we be doing instead?
Two things:
Try to shift the conversation towards value instead of timelines. Everything I said about estimates being uncertain, the same can be said about value. Without following the right approach, the amount of value uncertainty will be sky-high. You can nail your timeline, but who cares if it doesn’t deliver value. Next time an internal stakeholder asks for a timeline, ask them to tell you how much value the previous feature they were bugging you over is delivering. If you are sure what you are doing is the most valuable thing you can do right now, then who cares if it takes longer than expected. You should anticipate that any time expectation was highly likely to be flawed from the start.
Forecast timelines to your stakeholders. At every Sprint Review, forecast timelines of interest to your stakeholders. Update your forecast as more is learned. Stress that any timeline is based on the currently available information and will become more accurate as more is learned. Just like with a weather forecast.
What makes it really tough is that updating your initial estimates can make it seem like you don’t know what you’re doing. Unfortunately, this is often the truth. You usually only find out exactly what needs to happen by actually doing it.
As a former colleague, Jasper Bogers, phrased beautifully:
“Management often doubts your capability to deliver when what they’re really struggling with is your capability to predict.” — Jasper Bogers
So what are best-practices to meet timelines when you do have a hard deadline you need to meet? How can you forecast as accurately as possible? I will provide answers to all these questions in a future article.