Claude Montpetit -- Montpetit.net -- en

This is an excerpt of a post from Ken Schwaber, one of the authors of Agile Management with Scrum on the Scrum mailing list:

In my experience, if you reward people for something, they will do it. If you tell them you want esimates to more closely approximate actuals, they will do it. Will more product be built, or a better product be built? No, but we'll feel like things are more under control, which of course they aren't.

Nicely said; being better at estimates means you are better at estimates, not that you are more productive. This is an important statement. Of course, being good at estimates is important for a business where estimations are critical: In a fixed-price context, being bad with estimates is a bad thing; In a stand-alone product development context, marketing department promising feature delivery based on bad estimates is also a bad thing. But the important thing here is that productivity of the development team does not depend on the quality of estimates.

At first, I felt as if the last part of Ken's excerpt was not true. But if we assume we have a development process that is fully efficient, the estimate does not affect the control we have on this process: the development progresses efficiently despite a bad estimate.

So given these facts, and given only the two following options, which one is better: a bad development process with good estimations or a good development process with bad estimations? Of course, both process and estimation equally good is the best but stillI have my own answer.

Update: In the context above, a bad development process is one that results in a customer getting something he did not ask for, or not getting anything at all. Therefore, the 2 options could also be presented as follow: Is it better to deliver in the estimated time a product that does not meet the expectations of the client, or deliver a product that meets the expectations of the client at a time that exceeds the original estimation?