Estimating tasks to hours doesn't produce the desired result

2013-08-20

Here’s a great article discussing just that. http://agile.dzone.com/articles/estimating-tasks-hours-local.

Bottom-line. People don’t want to fail. So, forcing them to provide a precise estimate, and treating it as a commitment will result in people forcing themselves to meet the commitment. If they’re not quite done, they’ll do a rush job. If they’re done early, rather than moving on to the next logical item, they’ll ‘find something to do’. Regardless, people won’t get to work on the most effective thing.

Here are several links to why people have issues with estimation. Humans are notoriously bad at estimating. We all naturally underestimate everything. A lot of it is cognitive biases. There’s a long list on Wikipedia. http://en.wikipedia.org/wiki/List_of_cognitive_biases.

One we see all the time is the Fundamental Attribution Error. This is the phenomonen whereby the last person or group to touch something must be at fault for the failure. This commonly manifests itself on large projects where QA is performed at the end of the process. QA gets blamed, and called to slow, but they’re merely pointing out the issues, and are a symptom of the upstream problems in the project.

Another is the Planning Fallacy http://en.wikipedia.org/wiki/Planning_fallacy combined with Hofstadter’s law http://en.wikipedia.org/wiki/Hofstadter%27s_law

Bottom-line. Forcing people to give a precise estimate does nothing to ensure the estimate is accurate. Us humans are terrible at estimating, and even more so if it’s a task we’re going to work on.

So, stop trying to do precise estimates. It doesn’t help the success of the project, nor provide an accurate view of when a project will be complete. It delays the project, and burdens the team members.


Comments: