The oxymoron of “accurate estimates” might be amusing if it wasn’t for the fact that so many people in software development are asked for them. Recently I really enjoyed reading Bruce P. Henry’s blog post titled Statistical Frustration because it underlines the fact that it is impossible to say exactly how long something will take with 100% certainty.
I learned most of what I know about estimating from Steve McConnell’s book Rapid Development. Like Bruce, he also talks about the fact that you can not know for sure how long it will take to complete a project until you…er…complete it. Soberingly he gives some indication of how accurate you can expect an estimate to be at different stages of development. For example, when all you have is a concept of what you are aiming to achieve, he says your estimate could easily be out by a factor of 4. After you have firm requirements this reduces to a factor of 1.5. So even with totally fixed requirements (an unusual scenario) what you think will need 100 days of effort could require as much as 150 days but may only need 67.
The estimating advice in Rapid Development focusses on deriving effort estimates from size estimates. With this approach you estimate the size of what you are developing (i.e. 10,000 lines of code) and then convert this into effort using metrics. This works quite well at a conceptual stage. However, as development progresses your team gains a greater understanding of what you are trying to achieve. At this stage I have found that gathering estimates for individual tasks and then adding them all together will give a more accurate result. Indeed this is the approach that Extreme Programming recommends.
With all of this in mind here is my quick guide to estimating for software development:
Always Estimate in Ranges
Any estimate you ever produce or ask for should be expressed as a range. The lowest figure should represent how long you would expect it to take if everything goes well. The highest figure should represent a worst case scenario.
Cautionary note: In my experience it is rare that work is completed more quickly than the best case estimate. Unfortunately it is far more common that it takes longer than the “worst case” estimate. Check that people are being sufficiently pessimistic with their worst case estimates by asking “what if” questions.
Use a Technique Dependent on What You Know
If the work you are about to undertake is totally new to you (and you don’t know anyone else who has some experience) then function points or lines of code can be useful. Using estimation tools (like Construx Estimate which is free) can also help you in this scenario. If you don’t yet know what your technical solution will look like then accept the uncertainty. Sanity check the ranges of your estimates against the figures in Rapid Development. If you are at the conceptual stage and your estimate is 95 – 105 days then you are probably being optimistic about how accurate your estimate is.
Conversely if you know a lot about your development project then you may be better off using other techniques. Once coding has started often the best source of estimates will be the developers who are going to be doing the coding.
Refine Your Estimates
As you learn more your estimates should be refined and the techniques you use will need to change. I wrote more about this in my post on Embracing Change at Construx Software Best Practices. Keep an eye on the ranges of your estimates too. Theoretically they should be converging as the project progresses. If they are not you need to ask yourself why?
Convert Carefully From Effort to Duration
6 months of effort translates to 6 people for 1 month doesn’t it? This is a common assumption. Actually you have to consider a number of factors:
The overhead of working in a team (1 developer for six months achieves more than 6 developers in 1 month)
How many hours per day can you expect from people working on your project (see Steve McConnell’s recent post on this)
How many days can you expect per month (remember to allow for annual leave, training, sick leave and other commitments)?
During initial stages of estimation you can use tables (such as those contained in Rapid Development) to convert from effort to duration. Later your project plan should take account of annual leave and other commitments that those working on the project have.
Many consider software estimation to be difficult, a black art or even, in Jeff Staddon’s case, impossible. I don’t agree and believe that if you follow the advice above you will find that estimating is, in fact, relatively easy. The key is to remember what I started off this post by saying: there is no such thing as an accurate estimate.