Software Estimates - Over Estimate or Under Estimate?
Thursday, September 11, 2008 at 11:06PM Like most developers, I'm asked on a relatively consistent basis by project managers and clients to provide estimates of time and resources involved with completing a given task. Being the somewhat conservative person I am, I tend to pad my estimates - or simply put, overestimate. My rationale for doing this is to account for unforeseen events.
In an effort to improve my estimation skills, I've started reading the book "Software Estimation - Demystifying the Black Art" by Steve McConnell. Much to my interest, the third chapter - "The Value of Acurate Estimates" directly addresses the issue of overestimating vs. underestimating. The author points out that overestimation is the more common route that software estimators take for a simple reason - the ramifications of underestimating are much greater than overestimation. We can all probably do the math on this one.
Taking into account 2 factors, the first being that most estimates are overestimates and the second being Parkinson's law, one obvious result emerges. Project stakeholders catch onto this, and this is where pressure comes into play - pressure to squeeze out that extra time that was included to 'pad' the estimate. This isn't always a big problem, but it becomes a big problem when what we thought was an overestimate really ends up being an underestimate. The minute this becomes obvious to management and developers is usually when it's too late. McConnel describes the time consuming activities that 'snowball' as a result, forcing the task over budget and / or past deadline such as re-estimation, more meetings in an attempt to re-group, and worst of all - fixing "quick and dirty" code.
The best estimate is one that's 100% accurate, but that almost never happens. As a result decision makers are likely subconsciously adjusting our estimates downward based on the estimation trends I just discussed. So where does that leave the estimators? Is it ok to consistently give over-estimates, even when a more accurate estimate is available?
Just some food for thought...
Reader Comments (1)
Good post. I subscribe to some of the Extreme Programming ideas. One of wich is velocity tracking. From this, I tend to estimate my tasks in "units" that have a ratio to actual hours. For example it will take me 20 units to build a log-in screen for this application. Before the task starts, my ratio of units to hours may be 1:1. After I complete the task, I track how many hours it actually took me which may put my ratio closer to 2:3. When I'm estimating my next task if I identify that it will take me 10 units, I can more accurately tell the PM that it will take me 15 hours. As the project moves on, keeping track of this ratio becomes very valuable. The estimates that you give near the end of the project are the most critical as they naturally have less room for error.