An Estimate is an Estimate is an Estimate

Hi folks,

With the next two blog entries will take a look at effort estimation in agile and classic projects, because both methodologies are remarkably different.

First, let’s look at the classic estimation approach, which basically goes like this:
Usually you start with rough application architecture and gradually refine it till you end up with detailed design describing each feature and its associated tasks.

Next, you estimate each task in hours, add them up, divide the results be the number of developers, add the result to the current date and that’s when the project is done. Indeed that’s when product management expects the project to be done, that’s when it has to be done.

There are a couple of things wrong with this approach.

Estimates are estimates

People tend to forget that an estimate actually is an estimate. It’s nothing more than an educated guess and thus wrong the moment you voice it. If you actually knew how long a task would take, there wouldn’t be the need to estimate it in the first place.

Unfortunately many people take those estimates as axiomatic truths and want to hold somebody responsible if it slides.

This leads to the bizarre situation where the estimators already add a safety margin, because they must not exceed the estimate. Product management on the other side knows this and subtracts a portion or expects the developers to be faster.

So the parties are planning, probably even negotiating the project with values that have no reference to reality what so ever.

Developers not doing the estimates

Often the people who do the estimates are not the people who actually do the work. Estimates are decided by a committee and developers very seldom get asked. At best it’s the lead developer who then has to decide for the whole team and thus is under a lot of pressure from both sides.

How can anyone expect to get authoritative values if you don’t ask the people who know best? That is the developers.

Furthermore why should developers feel committed to the estimated deadline if they didn’t have a say in it?

Duration vs. Complexity

Another issue occurs when you try to estimate the duration of a task.

In software development the efficiency between developers can vary greatly. A very good developer can be up to 25 times faster than a mediocre developer. So even if you could estimate precisely, which estimate is it going to be?

Estimate based on the good developer? That’s not very realistic and you will almost definitely blow the deadline. If you base it on the mediocre one, you most likely don’t get the contract. Furthermore you can’t possibly know which developer will be working on which feature. So, again you’re planning with values which do not reflect reality.

Conclusion

As you can see, the classic approach has various issues which make it very hard to come up with a realistic and dependable plan, because you’re simply lacking realistic and dependable data.

Agile planning employs various methodologies like estimation in story points, which do not exhibit those issues. Next week we'll look at those methodologies in detail.

Cheers,
M.