Simple software estimation guidelines

As software developers, a common problem we face is trying to estimate how long it might take to build some idea still locked in a customer's head. Many legacy, high ceremony processes try to use highly precise measurement systems (man-hours etc) to measure this. A problem with this approach is that they very often fail or give deceptive results because of their inability to account for a confidence factor and changing events. Put another way, these methods are precise, but inaccurate.
Many agile frameworks attempt to fix this by decoupling the estimation process from reality. They do things like use "points" or "high medium low" and then use historical data to adjust velocities based on actual performance. This approach has the advantage of acknowledging uncertainty and the inherent inaccuracy estimation often contains, it has a major flaw in that advance resource planning and scheduling can become a nightmare.
My approach is to blend of both these approaches: Estimate things by using hours, days, weeks, and "I don't know". This has the advantage of being fairly vague and can be used like the arbitrary numbers that the agile processes espouse, but also has the advantage of immediately letting stakeholders perform resource planning and start to build a schedule.

Comments

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image