On the risk of estimations
On the risk of estimations
A story explaining to developers how estimates are treated by the business team
A story explaining to developers how estimates are treated by the business team
Estimates are a fairly fundamental part of being a developer. However, there’s a common trap I’ve seen developers fall in to which sets everyones expectations in such a way they’re bound to fail. Broadly, the unstated expectation that is only resolved too late is the variability of estimations.
Mismatched expectations
We, as developers, spend the vast majority of our time coming to grips with whatever it is that we’re doing. Writing code is usually fairly easy; understanding it is far more complex. While writing code we often try several different strategies trying to mesh our ideas with the ideas of those who’ve written the code before us. It’s a problematic task at best — sometimes it works, sometimes it doesn’t. However, it does mean that sometimes we’re fundamentally wrong about our assessment, and work takes 2–3 times longer than we imagined it should.
However, this isn’t apparent at all from the business side. In the eyes of business they’re using estimates to determine whether a project should go ahead at all, rather than determining how long it will take. Accordingly, when we return to the business team with the less than exciting news that the estimate is now 3x what it was, they’re understandably less than impressed.
Making things clearer
There are a few things we can do to mitigate the risk of annoying our business partners:
Give a confidence level in our estimate. For example, it’s better to say “It should take 1 day, but this project has a history of being difficult. 4 days” rather than “Oh, 1 day, but this is an estimate”
Factor in the worst case in our estimates. For example, “This will take 4 days”. Shocked business owners will ask why an estimate is so high, which is invitation to explain the risks, as well as notify them that it’s possible that it will be less than the provided estimate.
Raise the increased estimate as soon as it might take that long. The sooner the estimate is revised, the less money potentially burned heading in the wrong direction.
In the worst case, the business team will determine the risk for a given project is too high, or the estimate too large and scrap it.
Both of these outcomes are fine.
It’s not on us to determine the direction of the business; we have the fine minds of the business team for that. However, they do need reliable and predictable estimations to be able to make the business predictable — to keep us in work.
In Summary
Estimates can mean different things to different people. Take the time and make your estimates explicit; clearly explain what the risks to a given estimate are, and why those risks are present.
With that we can all be much more predictable in matching our estimates, and our business partner will happily keep assigning us interesting work. We will all be much happier just by being honest with ourselves and our partners up front.