Accurate Estimation: An Oxymoron

A developer friend recently asked how to handle it when the business side of the company insists on not only constraining delivery date and scope but also on moving the date up and asking them to “make it so.”

This is a form of disfunction I see often and while there are super visionaries like Steve Jobs who seem to be able to inspire super human action through the clarity of their vision, situations like that are incredibly rare.

Dealing with a situation like this takes courage and tact. I thought you might be interested in my response to him.

– —
Dear _____,

First let me say that the situation you are in is both typical and challenging. And second let me offer that there may not be an easy way out of this. It is an interpersonal/cultural problem more than it is a “how do we estimate better” problem.

We humans are all bad at estimating. Breaking things down into tasks then putting hours to those tasks then adding them up to get an overall project plan and delivery date is very tempting. It gives a very powerful illusion of accuracy but in reality it is far from accurate.

This is because humans tend to underestimate how long something will take to do. This is a statistical reality across industries, teams and individuals. So when we use aggregated task hours for large estimates there is an error amplification effect with the end result that we are usually very very late.

A much more accurate way to go is to group things together with other similar things — small, medium, large etc. Then apply a measure — I prefer story points in a fibonacci sequence — to each group. If we track our historical performance over time in these points we can then look forward in our backlog to estimate a delivery date with a relatively high degree of accuracy.

This kind of estimating though takes time, discipline and a safe environment to develop a mature practice. This is where culture comes in.

You need a safe-to-fail culture to do good work. Show me a culture where failure is not an option and I’ll show you a culture that will never be successful. Until business and IT can agree to share risk around estimates it will be difficult to get anywhere.

The only way to ensure you hit a date is to have the freedom to limit scope. Teams can eventually learn how to increase speed — to a point — but ONLY when they are mature, self-organizing and self-directed. This means that management must respect their estimates and create a space that is safe to experiment and safe to fail.

Your job is therefore not to estimate better but to work with the business and help them to understand your situation and find an ally on the business side to act as Product Owner who will share the job of estimating with IT. Unfortunately this often means setting boundaries, which can be very unpopular.

It’s up to you therefore to assess whether you want to either fight for things to be done right (which may mean losing your job), manage as best you can with small incremental improvements to a tough situation (which can be a form of slow, painful death) or seek opportunities elsewhere.

I wish you all the best in whatever you do,
Bob

1 Comment to Accurate Estimation: An Oxymoron

1. 

   Excellent points Bob! First chapter of my book is “Give yourself more time for everything,” in keeping with our predilection for underestimating. It’s like we forget about Murphy’s Law, not to mention the cumulative impact of tiny delaying factors throughout a process. So at the risk of exposing my total geekiness, Mr. Scott from Star Trek was a master of estimation, who we can all take a lesson from. He made his best estimation, then tripled it. As he told Bones in Star Trek IV: “how do you think I keep my reputation as a miracle worker?!” We may not have the option of tripling, (your point about losing one’s job) but I personally find multiplying by 1.25 to 1.5 ends up being pretty accurate.
Ian Blei on May 26th, 2012