February 14, 2009

Software estimation

Filed under: Estimation — Freek Leemhuis @ 9:44 pm


I have been trying to improve my estimating skills recently, I have always found it hard to do but I thought I’d share the things I have picked up that can make it somewhat easier to deal with.

Breaking up is hard to do

A question you get asked a lot from managerial types is: read these documents, then tell me how much will it cost to build this thing? It doesn’t have to be accurate, just give me a ball park figure. Are we talking three hundred, five or maybe eight hundred thousand euros?

Don’t do it. Even if you have an idea (it’s probably closer to twelve hundred), don’t say it. Don’t trust your ‘expert opinion’, because it is a very unreliable tool for performing a realistic estimate of this size. You can be way off. And if you are, it will come back and bite you in the a**.

The only way to get a reliable estimate is of course is to decompose the requirements into a work breakdown structure. The smaller the chunks, the better your estimate will be. It is so much easier to estimate a small size, and the process of breaking up large tasks into smaller ones will give you a much better idea of what needs to be done. I usually try to break down tasks into subtasks that are no larger then a day’s work.

What can possibly go wrong?

When preparing a quote we often need to align different estimates, and usually my estimates are higher then anyone else’s. Still, I’m usually convinced that mine are the more accurate 🙂

One thing that I picked up from reading Steve McConnel’s excellent book on Software Estimation is the Program Evaluation and Review Technique (PERT). This technique has been developed to counteract the natural tendency to estimate according to best case scenarios.

It turns out that if you ask a developer for a single point estimate, and then ask him to give a best case and a worst case scenario estimate, the single point estimate is in most cases very close to or equal to the best case scenario.

The PERT technique will counter this effect by asking to provide best case and worse case estimates, and also the mostl likely case estimate. A formula is then used to compute an expected case like so:

Expected Case = [Best Case + (4 * Most Likely Case) + Worst Case] / 6

Still, people tend to be optimistic when creating ‘most likely’ estimates, which is why Stutzke has presented an slightly altered variation :

Expected Case = [Best Case + (3 * Most Likely Case) + (2 * Worst Case)] / 6

If you are new to estimating, you will find that using this last formula will give you higher estimates. You will also find that they are much more accurate.

How long did you say this was gonna take you?

I didn’t, since I’m not the one that is actually going to build/test/document the system. Someone else is. So the estimate should be based on how long the task is going to take the person that is actually going to perform it.

I see a lot of estimates created by senior developers, and they can be a bit arrogant in their evaluation of the tasks. “Huh, I’ve build something similar on a number of occasions, it’s not so hard. This will take me only xx amount of time.”

Tough luck for the poor schmuck that is going to perform the task and has never done anything like it before. The estimate can not be wrong, can it, since it was done by someone with greater experience! So why is it taking so much time to implement this feature?

Keep it mean & lean, okay?

Finally, commercial considerations will often drive a sales manager, keen to make a sale, to give a few pointers as to what type of estimate he needs. “This client has money to burn, so don’t be shy”. Or, more likely, “We need to make this sale so keep it lean & mean, okay?”

Don’t let any of this influence your estimate in any way. Your job is to create an estimate of the size of the work that is involved. An estimator needs to provide estimate that is as accurate as possible, and the manager can decide, based on the accurate estimate, what to do about pricing or other considerations to make his pitch.


Create a free website or blog at