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.
Received the following comment via email – thanks, Ed!
“Should you include the PURPOSE of the estimate. When I did estimates, the purpose for which they were intended predetermined how thorough they were. Was it for conceptualizing the project, budgeting, capitalization, project approval, scheduling resources… “
Great post, Indeed!I have recently started reading all your posts in the archives as well and they make an excellent learning database. I would like to add something more to this post.
How does “Estimate by analogy” ensure that we improve in software delivery every time? Possibly a combination of “Estimate by analogy” and “Use expert judgement” together can bring good results. In embedded systems code, I have seen (in lesser samples) the estimates to be badly beaten whenever algorithm estimates were prepared with good amount of effort.
We can not discount the fact the Software estimation is a difficult skill to master and is also very much a function of people who will implement the software.
Bikram, thanks very much for the kind words, and for reading here!
You make a great point about improvement over time. My experience has been that _only_ a post-mortem on estimates can lead to improved estimation skills. The person who created the estimates tracks actual time spent, and then reconciles it.
On one project where I lead 5 people through about a dozen three week timeboxes, we had an interesting effect – people began beating their estimates consistently in the later cycles of the project.
The estimates were a combination of ‘by analogy’ and ‘expert judgement’. The developers were not trying to improve their estimation skills during the project, and their estimates were consistent.
I believe that the architectural decisions at the beginning of the project made their work progressively easier to accomplish, allowing them to beat estimates. It may be that they simply became more adept in the domain of this particular project.
Thanks again,
Scott
You are right that no all estimation tecniques are good for all projects. However use a ONLY estimation tecnique to see the future is not a good practice.
If you want to know the future, you need differentes perspectives, for example you can use
1. Expert Judgement
2. Analogy
3. FP
4. UCPS
And with this scenario you can merge ( get a central point) and get the “real future”.
Also, that you say, We deliver software incrementally, so we can estimate incrementally. Remeber uncertain cone http://www.construx.com/Page.aspx?hid=1648. Yer I know that our clients dont like it, but its no necesary tell them this, but this estimation can use it to project control.
Have a nice day-
Juan Carlos, thanks for the comment and welcome to Tyner Blain!
You’re exactly right – having multiple forms of estimation for any given task gives you greater confidence (when they all reach similar conclusions) in your estimates. Errors with one approach tend to be offset by errors introduced by the others.
Thanks again!