May 23, 2006
Tom Looy says "Stop Estimating!"
Accurately estimating software development projects is hard. Original estimates are notoriously bad.
Tom Looy takes this industry experience, turns it on its head and implores us to stop estimating. That's right. No more requests for estimates of how much effort left for a particular task. No more "90% complete" answers. If we're so bad at estimating why waste our time on it? It's a fair question.
Instead, Tom advises us to measure our progress. And by that he means in terms of completed tasks. Critically, he stresses the need to start measuring progress early in the project. As he says, and as I've seen far too frequently, often no assessment of completed tasks is done until it is too late to adapt the plan. Without stealing all of Tom's thunder, here are his key suggestions:
- Stop estimating
- Prioritise requirements
- Gather requirements just in time to enable developers to start coding
- Measure progress (only completed tasks count)
- Measure using smaller sized tasks
- Start measuring as soon as possible
- Use measurements to validate original estimates and adapt the plan to reality
I agree whole-heartedly with Tom's excellent article. He presents a realistic approach based on experience and common sense.
It is also an approach that I think would significantly reduce stress in the software development workplace. Stress is so often caused by an unwillingness to accept reality. So let's adopt a realistic approach and get on with the business of developing software that benefits people in both the customer and provider organisations!
Reflecting upon Tom's words I find myself pondering the following challenges:
- How does one convince customers and development managers to accept that estimates are fundamentally unreliable?
- How does one persuade the customer, who naturally wants more certainty, to accept this approach?
- How does one influence a development manager to track progress from an early stage and adapt the plan to reality?
I have seen this sentiment in many "agile" approaches, and in many ways I agree with it, but to recommend no estimating at all seems very limited in applicability.
In any reasonably large development there are pretty much bound to be several separately developed systems, each with their own needs, priorities and roadmaps. In addition, there are likely to be resource issues such as hardware to build or purchase and people to recruit.
With all of this the major issue is one of coordinating things and ensuring that things are ready in time for when they are needed.
If all resources were present at the start of the project and the development was entirely "free running" with no external dependencies, then estmiation would not be needed, but in my experience this is rarely the case.
Posted by: Frank Carver at May 24, 2006 3:00 AM