How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.
Context
We deliver software incrementally. Each release will include a set of requirements that enable one or more use cases, because half a use case is worthless. Each use case can be traced to a set of requirements, the designs that they drive, and the code and tests that implement them.
We prioritize our desired functionality in the order that we want it to be implemented. We schedule the functionality based on how long it takes to implement it. Within each release, we create a timebox and fill it up with functionality based upon the estimates for how long the work takes. And we use PERT estimates for our tasks.
But where did those PERT numbers come from?
Types of Estimates
There are five common methods of creating estimates, according to the Software Estimation Technology Report. We don’t have to use the same type of estimate for all of our estimates within a project, and probably shouldn’t. Every estimate should use one of these approaches, and should document which approach is used.
- Estimate by Analogy
- Estimate from the Bottom Up
- Estimate from the Top Down
- Use Expert Judgement
- Estimate Algorithmically
Estimate by Analogy
Use knowledge of previous, similar tasks to create the estimates. We apply what we experienced in previous efforts to what we’re estimating today. This is applying the actual values as approximations for the new activities. This approach suffers when historical data does not closely match the activity we’re estimating.
Estimate from the Bottom Up
Perform detailed estimates of the smallest elements of each task, then roll them up. This type of estimate is very effective because smaller tasks are easier to estimate accurately. The problem with this approach is that we risk spending too much time creating estimates.
Estimate from the Top Down
This is an approach to estimating an entire project, rather than it’s constituent parts. We’ve listed it for completeness, but it doesn’t apply to creating estimates in this workflow. It is valuable for creating pre-planning ROM (rough order of magnitude) estimates. This approach looks at the big picture – integration points, system level estimation, etc. It has the benefit of being very fast, and the detriment of being very coarse.
Use Expert Judgement
Because our guru said so. We apply what we learned in past projects to create estimates for this task. These estimates are only as good as our gurus.
Estimate Algorithmically
Use an estimate of lines of code, or function points, or objects anticipated with the design for the task to create an estimate. This has the benefit of appearing to be very precise. The danger is that it appears to be precise. Here’s a Gedanken experiment for you: Which task will take longer – the one with 100 function points in project A, or the one with 100 function points in project B?
This is like estimating how long it will take to walk 20 miles, with little insight into the terrain.
Conclusion
There are many ways to approach estimation. Each task will have one or two comfortable approaches – use one of those. And document the estimation method, so that the project manager can better account for the risk of bad estimates.
Latest Articles
Comments on all Articles
