Estimation

1. Nobody ever does it. In fact, I donâ€™t even know of a process to achieve this. Hollering at people who over/under estimate is not an improvement process.
2. It assumes you can make developer estimates better. More experienced developers estimate better, that Iâ€™ll take as a given, but can you accelerate this with novice/junior developers or testers?…
3. Software is NOT like mechanical engineering. It is a craft. … So our inability to accurately and precisely estimate shouldnâ€™t be all that surprising.

Personally, I believe that these claims are false.

People estimate all the time – Velocity based on complexity, jellybeans, gummy bears and ideal hours are all fairly rigorous forms of estimation, when they’re done consistently.

There is plenty of evidence that mechanisms such as the Delphi Method do, in fact, make the general estimate far better, even when you include a mix of junior and senior developers. I use this extensively, and it has never done me harm yet. When you have five smart people discussing how hard a particular task is, you find out the different perspectives quite quickly.

While I agree that software is a craft of creativity, no one (that I know of) thinks that estimates have to be train-schedule accurate and/or precise. When I wear my project manager hat, I just want a general feel about how many tasks will fit into my two week iterations.