Why estimates suck
It may not be what you think
When engineers give estimates, it’s typically the focus time for stories. That is, we think through what is needed to make the code changes for a story and estimate the time needed to make, test and integrate those changes, provided we had focused time to work on that story for the duration.
The challenge is that most people who ask for estimates expect you to estimate the wall clock time needed to deliver work from start to finish or the flow time.
First of all, if you’ve ever written code, you know that there is often a significant error in the estimated focus time and actual focus time..that two-line change you made leads to a cascading change of test failures that then leads to reverting back to the starting point 3 hours later, etc. We’ve all been there. So there is some inherent variability in our estimates.
But in fact, if you look at estimates vs. actual approximate focus time across the work that a team delivers over longer stretches of time, on average, they are pretty well correlated in most cases. In other words, most of the time, developers’ estimates of the actual focus time needed to make the actual code changes for a story are reasonably accurate.
I’ve seen this often enough in the clients I work with to the point it’s surprising when this is not the case.
On the other hand, if you look at the relationship between focus time vs cycle/flow time, there is often no correlation between the two.
The difference lies in the nearly random wait time introduced by your delivery process.
For reference, the cycle/flow time is the sum of focus time and wait time.
Key culprits for the random wait time:
Partially completed stories aging in place due to much WIP
Delays due to handoffs between team members
Lack of situational awareness of what work is actually waiting for action.
Multi-tasking and context switching
Fixing this is the domain of product development flow.
Improving the stability of the process means reducing the randomness introduced by process execution.
Improving flow efficiency throughout the delivery process means reducing system wait time as much as possible and making wait times more predictable in your process.
And it is possible to tackle all this systematically if you have the data.
If you get a handle on flow, no matter what development process you use, you have a much better chance of getting more predictable in your delivery, even with rough developer estimates.