Five Points To Improve Your Estimation
Software Estimation is tricky business. You are often confronted with complicated technical (or even non-technical) work and asked “how long will it take?” on the spot. You are given fuzzy requirements (or no requirements) with ambiguous definitions and have to work with a code base that is best described as “chaos”. How can you give an accurate estimate with such a difficult environment?
I recently read an excellent book called “Software Estimation: Demystifying The Black Art"
Here are some amazing points that you can use.
1) We should not be pressured to reduce our estimates. Stick to your estimates – whatever they are. If management wants to reduce them, that’s fine, but stick to whatever you put in the first place. Managers trying to reduce estimates is a very silly thing to do, because by looking at the track record of our software industry, you will find that we consistently underestimate, not overestimate! So if you are pressuring your developers to reduce the estimate, you are asking for trouble. Better thing to do would be to see if the estimate is well founded, based on task level estimates, or is the estimate based on unjustifiable assumptions, etc.
2) Underestimating is MORE expensive than overestimating. So if you cannot estimate accurately, lean towards overestimating. Underestimating has an exponential additional cost, whereas overestimating has a potential of a linear extra cost due to Parkinson’s law. This is because underestimating results in lots of other problems such as having extra meetings to justify why you are behind schedule, having extra meetings to decide which features to cut, added stress on developers trying to meet tight deadlines, code having less quality in order to ‘just finish it’ so that developers can go home, having customers get angry at not-ready releases, having other teams who are waiting for the code to slip their schedules too, etc.. If you overestimate, then Parkinson’s law can kick in and developers will ‘fill in the empty time’, or as they say ‘work expands to fill the available time’
3) Task level estimates are best done by the developer who will be doing the work. A task level estimate is defined as a low level estimate for a particular item of work. For example, for building a workflow engine, a task level estimate is “2 hours to add the save button that will commit the changes to the database”.
4) With small teams (say under 5 people), estimates are most accurate when done bottom-up (i.e. from the developers). What this means is your complicated formulas for estimation are not so helpful in such environments.
5) There are many other ways to estimate such as ‘estimation by analogy’ (i.e. by looking at a similar project that was built), and so on, but I won’t explain those right now. The trick in general is to try to quantify as much as possible and leave subjectivity out of the picture. So if you can find out how similar your project is in terms of number of lines of codes, number of features, etc, you will have a better estimate. As well, don’t be fooled into thinking that more “estimation knobs” will give you a better result than less “estimation knobs”. I define an estimation knob as some sort of criteria you are using to estimate, such as “size of team”, “team programmer skills as a percentile of the industry”, “how many burgers they had for lunch”, etc.. It looks like it would give you a better result but in reality the estimate becomes more and more subjective as you add more “knobs”
As well, developers are more likely to try to meet their estimates if they are the ones who gave it, rather than if its dictated to them from above.
Lastly, estimation is a skill we can learn and improve over time. You will find that over the months, your developers will get better at estimating based on past experience.
In summary, stick to giving your developers clear requirements, lock them down, and then get them to break down the requirements into task items, and then estimate for those task items.
Other Interesting Posts
2 Comments »
RSS feed for comments on this post. TrackBack URL
The key to estimation is Requirements/Feature Lock Down. If the requirements and features aren’t locked down for the current release cycle then you’re dealing with a moving target and thus all estimates are worthless, unless they shift with the target, but then they wouldn’t be useful estimates either.
Without that feature lock-down I’ve found the best answer is to blow the task out of the water. WAY over estimate it (More then double what you think it’ll take). I’ve found more often then not, that huge of-the-cuff estimate ends up being a lot closer to the real tasks needed time then seemed at first blush.
I’d rather loss the work then take on a project doomed to fail before it started just because the resources weren’t there to begin with.
Interesting point, but hard to justify all that time to your manager