Development Estimates Are Like Sausages

Have you heard the old quote from Otto von Bismarck that laws are like sausages, it is better not to see them being made? The same can hold true for estimates. Sometimes estimates and the method to arrive at them can be completely sound, but describing how you got there is never going to please everyone.

As you may have read in my post on user story estimates, I like to come up with raw estimates for each story, and then have a “factor” that applies to each one. This helps abstract the variable adjustments (average developer factor, raw code hours per day adjustment, requirements fudge factor) that apply to all stories from the raw estimate assigned to each story. Therefore, if you felt like the requirements were particularly buttoned down for a given project, your factor for requirements fudge factor might be less significant than on other projects. Changing this is a snap. Just update your factor, and all individual story estimates are automatically adjusted. No need for a manual update to each and every single edit.

Sounds reasonable, right? And yet it can still be tricky when a customer doesn’t grasp a raw estimate. If your factor is 1.5, all they see is that you are taking your estimates and adding 50%. I used to try explaining the process to people. Some get it, some don’t. At the end of the day, I don’t want the customer to have a false impression that they have been taken for a ride, and sometimes the factor gives the impression of an arbitrary buffer, when it isn't that at all.

The solution? Use the factor to determine final estimates, and then share the final estimates. Do not pass along the raw estimates or even attempt to describe the factor. With estimates, as with laws and sausages, it’s best to make them and then move on.