Great article! I’ve found estimation to be a tricky business because there are so many *what ifs*. One company i worked fort used a simple spreadsheet for test estimation and insisted on using an *industry standard* 6 hours per day (i was sceptical of this figure as i haven’t found any reference in relation to it) to calculate estimation. When i think back to it, i don’t think we were even *close* to the estimate when testing finished (i know its an estimate but even a ballpark figure would’ve been more useful!. Often when the *estimate* was *calculated*, we were *held* to this timeframe which led to testers overly inflating testing effort just to be safe (sure you build some fat in but….). Another place wanted an *exact estimate* for each individual test case (100+ test cases) - the rebellion rose pretty quickly and the PM only just managed to avoid a coup d’etat! And yet others are not really interested and just plough ahead.
When i’m asked to estimate i tend to rely on my gut feel and then i remind myself that an estimate is exactly that! Thanks for the blog - have fun at CAST2008!

The point of the article was that I don’t recommend using templates for estimation. Instead, I provide an example of how I might approach estimation for a project and I walk through the steps that I take.

If you find that you’ve been repeatedly estimating the same type of project, then you may find that you’ll save time with a template. I’ve found that I’ve rarely had two projects that were so similar that I would be able to reuse much documentation from the previous project.

Thanks,
Mike