Estimating - an art that everyone should know?

Fortunately, I am one of those lucky enough to be able to give estimates for my work. My company is mostly based on programmers estimating the technical work, which probably is one of the best things a business can do (just like leaving business people estimating business stuff). But do we really know how to estimate how much work a particular feature will take to implement? Maybe yes in some cases and no in others, but as agilists and perfectionists I think that we must constantly look back and improve.

Ok, so how is estimating done?

The best method of estimating is explained in K.Beck’s and M.Fowler’s book: Planning Extreme Programming: “Say you’ll do as much tomorrow as you actually got done today” meaning that the best method to estimate is to use your own previous experience. If personal experience is not good enough maybe you can use a colleague’s experience or be able to find a thing in the past that was twice as big as what you need to estimate, or twice as small. But be careful , because the further you get from your own experience when it comes to estimating, the lower the precision.

What happens if the work is new? Kent Beck said in the same book mentioned above that when you do not have experience is to fake it. Make a small prototype and estimate based on that prototype.

But why it still fails?

Ok now that I have emphasized how simple is to estimate, is this enough? Why there are still very many people, very good programmers that have big differences in estimates compared to actual time. What influences us when we are estimating? One cause might be that mostly nobody looks back and cares to take a note on how much a feature took to implement and how big was the error in estimate vs actual. The second thing would be in my opinion, either people are too relaxed or too pressured to give better estimates. The third in my list of reasons is that programmers who take pride in their own work usually give estimates in ideal time considering the best possible efficiency they might have. Is this something very wrong? No, I think that in many cases, it only shows the programmers need to outdo themselves, to test their own limits. This is very beneficial in some aspects, but applied for a long time might lead to demotivation and stress as the estimates are far from the actual time, stress that is at all levels, from the customer to the other teammates and even to the one that gave the estimate, who starts losing confidence in himself.

So what should we do?

My opinion is that first people must become aware of the importance of giving not perfect but better estimates, then start doing it, just as the Chinese said that the thousand miles walk begins with the first step. Then the most important thing, like in all agile methods is to look back and improve in time.



What do you think?


Dan Bunea