In the last post we covered the importance of engaging the right people in the estimation process and the need to use more than one estimation approach. Today we will look at some examples of team based estimation approaches and practical ways to combine estimate result sets.

Estimation approaches (agile or traditional) can be divided into Heuristic (expert judgment based) and Parametric (calculation based) approaches.

Heuristic
• Comparison to similar systems
• Expert Judgment
• Activity Based (top down)
• Task Based (bottom up)

Parametric
• Function Points
• Use Case Points
• Object Points

Both sets of approaches have some merit, but they are also have their limitations and are open to misuse and over reliance too. For instance Activity Based (top-down) estimating is the most commonly employed estimation approach, but has been found to be the least accurate. Capers Jones in his book “Estimating Software Costs” instead recommends task based (bottom up) estimating approaches that tend to yield better results by encouraging a more thorough investigation into the likely tasks.

Involving many stakeholders
We should ask the people who will be doing the work how long they think it will take. Not only are they closest to the technical details and therefore theoretically in a better position to create a better estimate, but also because of the psychological benefits also.

If someone just hands you an estimate for your work and tells you it should take two weeks, you can either comply and try to get it done in two weeks or rebel and either finish it early or explain why it will take much longer to illustrate the poor nature of the estimate. Even complying and doing the work in two weeks can be a problem; given two weeks work will expand to fill the time. If a solution is found early time will likely be spent finding a better solution or refining the existing one. We do not get enough of the early finishes to cancel out the late ones. As Don Reinertsen observes in “Managing the Design Factory” in engineering we get few early finishes.

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.