Agile Estimation – Upfront Estimates

This is the first of a couple of posts on agile estimation. I would like to thank Boris Mutafelija for submitting the topic request, while there has been much written on agile estimation; it is an area that comes up time and time again. Today I’ll cover the big picture view and upfront estimates.

First of all we need to understand that estimating software projects will always be problematic. It does not matter if it will be a traditional project or an agile one, software development projects are unique (we do not repeatedly build the same system) and the evaluation difficulties that make gathering upfront requirements tricky also make scoping and estimating hard too. So approach the problem conscious of the issues and limitations of any approach, keep in mind early estimates will have wide ranges of variability.

(Barry Boehm’s estimate convergence graph. At the time of Requirements Specification estimates are only likely to be in 1.5 X to 0.67X of the final project cost range. Calls for ± 10% are just not realistic on most software projects.)

Next we need to accept that at the start of a project, the estimation approach will be similar for agile or traditional projects. By this I mean we have very little to go on, probably no productivity data for the exact team undertaking the work and only a coarse grained view of the project scope and complexity. Agile projects become much easier to estimate once we have completed a few iterations and can start to gauge the true project velocity, but at the beginning we are in the same dilemma as traditional projects. Estimating the time required to build an unprecedented system with an unproven team.

As the project progresses and real project velocity metrics begin to emerge we can use this data as a means to predict when we really will be done. The advantage of using project velocity data is that is derived from actual project performance rather than projected or theoretical models. If we are only completing 50 stories a month and there are 200 stories left in the project then it will probably take us about 4 months to finish development. This may not be the answer we want to hear, but it is at least based on real performance. When estimating via models and formulae we are sometimes pressured to favour models that predict desirable outcome over the most likely.

Of course the velocity metrics that emerge from the very first iterations will not be representative of the later iteration velocities. Early on the project team is new and still passing through the Forming, Norming, Storming stages of team development. Plus the project environment (tools and techniques) may still be new to many and a good portion of time might be invested in iteration zero, infrastructure type work. However the proportion of these early work activities soon reduce and before long more realistic velocities surface. Our estimation approaches should mirror this emergence of better data. Early on we have to rely more on traditional techniques and then later can convert more towards velocity metrics, as shown below.

So, early in the project lifecysle, just what are these traditional estimation techniques we need to use for our agile projects? Well, any and all of the classic ones, including:

• Comparison to similar projects
• Function points or Story points
• Bottom up estimation of tasks
• Expert judgment
• Team based approaches

All of these approaches have some merit and all are very easy to criticize. However at the beginning of a project we have very little else to go on. When estimating we should remember and try to account for two things:

1) No one estimation technique is perfect (or even very good)
2) No one person produces a perfect estimate (or even very good)

Both techniques and people have flaws, yet we can mitigate the impact of these flaws by using more than one estimation technique and by engaging several people in the estimation process.

Where we can find convergence between different approaches and opinions, we should minimize the limitation of each component (or at least console ourselves that we did all we could and it is not just our fault!)

Next time we will look at estimation approaches such as Wideband Delphi, Planning Poker, Use Case Points, and Story Points. Until then remember that while estimates are vitally important to projects, their quality will be as good as their input data (typically poor) approaches used (typically too few), and people engaged (again, typically too few). So, try hard, frequently benchmark reality, and get as many people involved as you can (to share the blame!)

Comments

[Mike Best]

Thanks for this discussion on estimation. I find its still very needed in the Agile community. I do hope, however, that within this series you discuss the more difficult sort of estimation, that of task estimation within a sprint. Techniques for estimating tasks seem to get even less discussion than those for estimating Stories.

[AMukherjee]

Thanks for starting this discussion. The dilemma that is faced is I guess during iteration and task planning regarding what granularity should one go to. It is team based and need based, yes, but some guidelines could help.
Moreover, apart from core tasks there are additional efforts spent in collaboration,communication etc. How does one cater to these? Overheads?

[Mike Griffiths]

Hi Mike and AMukherjee,

Thank you both for your feedback and observations. I am happy to write additional posts on agile estimation, but would like to clarify your points.

Mike, you say you would like information on estimating tasks and not stories. I want to understand your definitions because these change between methodologies. In your mind are Stories (business value oriented) broken down into Tasks (technical steps) or do you have a different distinction?

AMukherjee, I think you are asking about non-development focussed overheads for meetings, administration, etc. Is this correct?

Please drop me a quick note, either here or to Mike (at) LeadingAnswers (dot) com, to confirm or clarify and I will gladly write a post to expand on these areas.

Best regards
Mike