Tuesday, August 19, 2008

Obfuscated Units of Time

Call them NUTS, Gummi Bears, T-Shirts, or whatever. If you can convert them directly to time you're doing your estimation WRONG. Let me say it another way: Estimates from developers do not correlate to the time expected to complete the feature.

Estimates from developers represent relative complexity among stories. For example "Feature A is twice as complex as Feature, B and since we said A is a relative complexity of five, Feature B is a ten".

And for the most part, assigning relative complexity is easy to do with little detail from the customer. "Gee, that sounds like all my User Stories!" Bingo.

BUT! (I know what you're thinking) Money is time, time is money. If I try to tell a customer or product owner "Well it's about 2,000" their first question should be "2,000 whats? What's the unit? How long will it take?" He wants time. The truth of the matter is you don't know. "They'll never buy anything from me if I can't give a time estimate." I know, trust me.

The tools Agile/Scrum provides for converting complexity to time are based on one thing: experience. The main tool you want to use is your Burn Down Chart which relies on a secondary tool, velocity, to predict when a team will finish a set of stories based on how they did in previous iterations in this release. After just one iteration you have a conversion factor from complexity to time, and it just gets more accurate as the release goes on.

Yet there's one spot, one tricky spot, the most important spot, the beginning. No work has been started, you have no velocity, but the customer needs to know if this is going to take five months or five years. Lie. Just kidding. Do the same thing that you always do, pull from your experience. Chances are your team isn't brand new, they've done similar projects, you can guess (the double that number) and start there. Consider a web project consisting of a series of forms with four team members. That's kind of like the project you did last year for another customer. There it had a complexity of sixty, and it took six months. Here we have a complexity of eighty, so one could come to the conclusion that it might take about eight months, so you pitch sixteen to the customer, and get started. Hopefully velocity will start to show that you will finish in eight, but if not, you have a good buffer to work with.

Remember, the conversion factor from estimates of complexity to real time is experience and the Burn Down Chart is you slide rule.

No comments: