Accurate Estimates

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.


2 comments so far

  1. daviddaly on

    Since writing this I found an interesting article by Jeff Patton on dealing with poor estimates for software development: Late Projects Caused By Poor Estimation and Other Red Herrings

    It is well worth a read but I would make the following two observations:

    1. A truly agile team should only be estimating 2-3 weeks worth of work at a time. Therefore there should be plenty of opportunities to refine estimates regularly. The issues that Jeff Patton describes are far more usual when more traditional development approaches are used.

    2. Jeff only talks about one estimating technique (asking developers how long something will take). At an early conceptual stage on a non-agile project that would not be my preferred method.

  2. daviddaly on

    Bruce P. Henry has subsequently posted again on the subject of estimating in Breaking Down a Project: How Much Detail? He confirms the view that estimates are best expressed as ranges. He also linked through to PM-Fu: How Much Detail Is Enough? which makes a case for estimating and managing software development in 1 day chunks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: