Why estimates suck

When engineers give estimates it’s typically for the touch 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.

If you’ve ever written code you know that there is often significant error in the estimated touch time and actual touch time..that two line change you made that leads to a cascading change of test failures, that then leads to a revert back to the starting point 3 hours later etc.. We’ve all been there. This leads us to think that it is impossible to estimate work accurately.

But in fact, if you look at estimates vs actual  approximate touch time across the work that a team delivers over longer stretches of time, they are pretty well correlated in most cases. In other words, most of the time, developers estimates of the actual touch 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 estimates 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 touch 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 this is the domain of flow management.

Improving flow efficiency throughout the delivery process means reducing 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 type of development process you use, you have a much better chance of getting more predictable in your delivery even with fairly rough estimates from developers.

The irony is that once you fix flow problems, you actually won’t need even those estimates as much either.