Granularity of testing estimates
Yesterday I was discussing how I do testing estimates with a peer here in Indianapolis. He pointed out that testers in his organization estimate things in days and hours:
- "That's half a day."
- "That will take a day."
- "That's likely 200 hours."
His concern with this technique, was that people didn't really understand where their estimates were coming from. In some cases, when he would ask how they arrived at their number, some testers didn't know. They just guessed.
Listening to him, I noticed that I have a pattern when I manage teams. Early on, when I'm working with a new team or people I've not worked with before, I look for estimates in minutes. For anything other than sessions, I want to see the breakdown of where the time's going in minutes. It's only after I've seen you estimate a couple of times that I'll take hours and days. This is because once I trust that you have a model that you're using to estimate, you no longer need to "show your work." If you don't have a model, then I'll help you develop one.
December 31st, 2009 - 09:52
I like to see more than a model — I also like to see how accurate their estimating is over a few instances. Seldom does someone hit their estimate every time, of course, but I find it instructive to see whether they’re off by the same factor every time, or if their outliers are for very good reasons, or whatever.