We’ve all been there. “How long will this take to get done?”. The answer they are looking for is “by this afternoon,” but most often the real answer is longer than that, often much longer. In fact, the real answer is “I don’t know”. But you have to give an answer. This is where you hear tales of people rolling dice or making something up or saying “six weeks” no matter what. In the end, you can’t know for sure because you’ve never done that project before, and so you make your best guess and it works out somehow most of the time.
But a lot of developers and managers fail to realize that there are really two different kinds of answers you can give. If it is Monday, you can say “I’ll have that done by Friday”. Then you work like crazy, and just before you go home on Friday, you deliver what you promised.
The other type of answer you can give is “That will take 40 hours.” And so if it is Monday, and you say that, then the manager will hear “I’ll have that by Friday”. So then you go and you work like crazy, and just before you go home on Friday you deliver what you promised. But when you’re done clocking all your time, you put in 50 hours to get the project done. That’s a 25% overrun, and your manager wants to know what happened and why you took so long.
There are a lot of things going on here – but the point I want to make is that there is a difference between an estimate and a target. An estimate – “How many hours is this going to take?” – is very difficult to get right. There are always unknown unknowns that enter in to make the total number of hours that something will take. We are notoriously bad at making estimates. There are a lot of reasons for that, but the fact remains that we are not really capable of making accurate estimates. But “I’ll have that by Friday” is easier to say because you have flexibility in the amount of work it takes to hit that target.
But note well that an estimate is not a target. A target is when you say “I’ll have that by Friday”. Saying that on Monday morning is not the same thing as saying “It will take 40 hours to do”. In fact, it’s a very, very different thing. Saying “I’ll have that by Friday” actually means “I’ll do whatever it takes – put it however many hours it takes – to get this done by Friday.” It might take 20 hours. It might take 60 hours. But you didn’t say anything about how many hours it would take, you gave the target point when it would be delivered.
So if you are a manager, recognize the difference between a target and an estimate. If you are asking for an estimate, understand that software estimation is still something even the most seasoned developers do very poorly. If you are asking for a target, realize you may be asking someone to put it a lot of hours to hit that target. Or not – maybe they say “Friday” and it only takes half an hour. Who can say for sure? If Friday is good enough, then you shouldn’t care how many hours it ends up taking either way.
And the one thing you shouldn’t do is ask for an estimate, take it as a target, and then get upset when the developer hits the target but runs over on the hours.
Targets are not estimates, and estimates are not targets. Understand the difference, and you’ll have happier developers and happier managers.
(this might be a repost – Disqus was acting weird the first time I tried to post this)
Nick,
Thanks for posting this.
I wish more people talked about the poor state of estimation skills in our industry. Steve McConnell published a great book on this topic called “Software Estimation: Demystifying the Black Art”. Your post echoes one of his book’s central themes: the difficulty in effective communication between developers and managers.
I think one pervasive assumption that needs to be knocked down is developers naturally become better at estimation as they gain more experience in software development. In other words, developers don’t need to be trained in estimation – they’ll just magically learn how to provide good estimates. In the last 30 years, this magic hasn’t happened to me, nor have I seen it happen to anyone else.
We already know good estimation skills are important. The hard answer both managers and developers need to accept is estimation is a separate and distinct skill from development. McConnell’s book makes a convincing argument, as well as providing a good starting point for developing that skill.
There are many proven approaches to software estimation. It’s not really that difficult.
Rick —
I’d love to see you point to a “proven approach” to software estimation.
I’ve had good luck with Scrum and XP styles of estimation (both are very similar). It boils down to measuring estimates against reality and using the average difference as your fudge factor for providing estimates in ranges rather than specifics. Over time, and with a lot of reflection, you get relatively small ranges (you might start off with ranges of months, but after a while get your accuracy down to plus or minus one week).
I told my boss I don’t know once because I have never done that before. It would be like asking me to estimate painting the Sistine Chapel. He said we should be able to estimate that too.
And that’s why estimation is an art, and not a science, like software development. My method is, I always give targets and work frantically to meet the target.
Estimation is a process, not a lucky guess.
When someone asks for an estimation, they should really get 3-4 responses. First an initial, rough “guess” (based on your experience from similar tasks), then you should provide an updated estimate when you have more insight into the sub-tasks (and where you have done more “guesses” on the each sub-task). Once you have started on the task, you should continuously adjust the estimate to the actual progress. Let’s say your initial estimate was 40h, and you’ve spent 10h to complete 1 out of 10 (equal) tasks, then it’s more likely that you’ll use 100h in total.
But by the time you’re finished with all the tasks, it’s no longer estimation..
..which is OK, because at that point you don’t need the estimation anymore 😉
You think management should estimate the efforts of other people, who’s work they are very likely to understand?
A project should have a project manager trained in things like GANTT charts and PERT charts.
Estimation and targets need to be delivered with confidence intervals. I believe that feature will take me around 40 hours, my confidence interval is +/- 10%, {19 times out of 20 | 9 times out 10 | 4 times out of 5 | 1 time out of 2}.
Managers who do not know what you mean above, by a confidence interval, do not deserve to be paid at all.
Secondly, I often say “I can give you an accurate estimate if I spend today doing research — shall I drop my bugs and get you a reasonable estimate, or shall I pull an answer out of a hat?”
Software estimation often fails because the role of what economist Frank Knight called “Fundamental Uncertainty” is poorly understood, if it is considered at all. This term refers to those situations in which you can not estimate the odds because you do not know enough yet about the subject. Every time a new technology is used in a project, it becomes impossible to calculate the risk/odds associated with the use of that technology. Since software developers, especially the younger ones, love trying new technology instead of old technology that could also do the job, software estimation is perennially failing. The solution to this problem is to eliminate the fundamental uncertainty as fast as possible. When starting a project, identify those things about which your team knows the least and either substitute something well known in their stead or learn what you need about the new technology to properly estimate the time it takes for its usage. There is no other solution to this problem.
XP and Agile and all the rest of the silver bullets are useless against fundamental uncertainty. You have to attack it directly.