The Fallacy Of Estimation Or Why Agile Needs Noestimates

Over the past month I have been talking to a few friends about their agile development projects. They are using different languages, with different size teams and most of them are tracking their projects using estimates of one form or another.

Whether they use points or attempt to guess at the time required for a task, they seem to be wrong a lot of the time.

It is rare that we have full specs or truly understand the problem at the start of a project (or even a sprint). We don’t have enough information to make accurate guesses and if we spend the time to gather this information, then we are often taking away from more productive work.

We can try to average the guesses with calculations of velocity or apply fudge factors to the guessed times, but this doesn’t solve the issue. We are inherently bad at estimation.

Jeff Atwood said in the comments of http://www.codinghorror.com/blog/2006/07/how-good-an-estimator-are-you-part-ii.html

You're saying that software estimation is impossible. I don't think that's true. It's a very hard problem, but it's not unsolvable. I think the main problem is most organizations don't gather enough data from their past and existing projects (bugs, bug fix rate, function points, etcetera), so they're starting from a blank estimation slate every time they launch a new project.

I personally don’t think that more data will help. I think it will just make the problem harder to solve. The real solution is really to do away with the estimates and just look at the work you are actually doing for feedback.

I think the only place where having no estimates falls down is when talking to clients. Clients like certainty on budgets and I don’t think we can change that. I think the only thing we can do is take a stab in the dark based breaking down the feature(s) into bite-sized tasks, the performance/skillset of your team, the type of work and your track record of work over the last few sprints. I just don’t think points and velocity add anything to the process.