Estimate, guesstimate, pest-i-mate

Here is a very good post on estimating the amount of time it will take for a software project. I got it from: http://blogs.msdn.com/anutthara/archive/2006/03/28/562989.aspx You are sitting in your office peacefully looking at the newly written specs for v1.1 of your product. You poke around at some code for that tool you always wanted to write - but the ship pressures didn't let you. As you glance at your inbox, there is an innocuous looking mail from your test manager asking you for an estimate of the test work for the components you own. What? How the heck are you supposed to estimate something that you know so little about? And just what is the basis of the estimate? This is so vague! Hmm...we could start with this: Break it down again… - Break down your component into smaller sub components that are separately testable. Further break these down into tasks that can be estimated in a fair way. For instance, consider an activity like creating sample repositories for migration in a PSConverter. You can split this into creating small, medium and big repositories. The big repositories can be further split into repositories for 10K, 50K and 100K actions. Split the medium and small repositories that way too – at the end you will have a set of tasks – each granular enough to estimate Déjà vu - Aw - come on, you've done this before. Activities that are similar to the ones that you have already done before can be estimated based on past experience. In the same instance as above, if you have created a 5K repository before, you can intelligently guess the time you would require to create a 10K or a 50K repository again. Use that experience wisely. Why God, why? - Against each estimate of a task, clearly document the justification for this time. If you have done the sub tasking part correctly, this part is a natural follow up. This documentation is as essential to the reviewer as it is to you. There is no way you are going to remember in M3 why you thought a particular activity would take 2 days when you have already spent the whole week on it and it is still unfinished. Call out caveats and special conditions clearly in your test estimate so that the reviewer is assured that you have factored these in into your estimate. But as Chris Shaffer, our TF test manager would put it, a world class tester won't just stop at that. You have a few more tricks to deal with this fuzzy monster: Bleeding edge technology please – We are not in stone age anymore - stop using crude methods to track your estimate. Get savvy - use Project or other tools to track your test tasks and work estimates. Not only do they supply useful features like sequencing tasks, marking start date and end date of an activity, graphically depicting size of tasks, associating tasks with custom tags etc, but are also much more maintainable and easily understandable. If tomorrow you move to work on a cooler project than your current one, the guy replacing you will have to understand your estimate, right? Back to square one - Iterate over and over your estimates regularly. Many new things may come to light as time goes by that force you to change estimates. A certain feature may expand its scope making you break it up into smaller tasks while another feature may altogether be cut leaving a gaping hole in your estimate. Don't obsess over task sizes and start estimating to the level of hours, minutes and seconds. In my opinion, a day is the most granular unit of time you can use to measure your estimates in M0. Where's my PM stick again? Now is a good chance to build more clarity into your spec just in case you missed out during the spec reviews. As you estimate your test work, you will have to think of the feature in a much more detailed manner, which will automatically reveal any gaps in the spec. Don’t sit on those – talk to your PM straightaway and bridge those gaps. A spec is a tester's insurance - hold it close to your heart. Buffer overruns are good for you – Allocate a good amount of buffer for unforeseen circumstances. Don't plan too close to the edges – you would certainly have missed something. Based on the ambiguity of the task, you may have to allocate anywhere between 30%-70% of buffer overrun to the task. Don't fret – your manager won't think you are a moron if you ask for 3 days to come up with a test plan for a simple feature – just make sure that you write a complete and well thought out test plan. Another thing to remember is consult your lead – she'll probably give a bigger estimate than you have, but will consider many other factors that you may have overlooked. The ultimate truth – All said and done, this is one of the fuzziest activities in the cycle and is guaranteed to come with a high margin for error. Stop looking for perfection in your estimates. Do your best to factor in all possible eventualities to come up with a sane and realistic estimate – but don't get depressed if you overshoot it later on – you'll get better with time.