Making better estimates, the easy way 0
As a programmer, coder, developer, manager, etc your often asked (usually at the most inconvenient of times) how long will this take to do? It’s at this point you normally put your finger in the air, check the wind and make a guesstimate, unfortunately these guesstimates often have a habit of becoming exact deadlines. Well no more, I’ll show you a two easy ways to avoid this situation and improve your estimates.
Getting out of jail
The next time you get caught of guard to make an estimate, don’t! Avoid this situation at all costs. Although this sounds impossible its really not, here’s how its done…
“How long will it take you to write a script to do A, B and C?” “We’ll that depends, A isn’t too difficult, i know John had trouble with B last time and I’ve never looked into C before but can I have a look around and get back to you later today?”In one sentence I just used 3 techniques - calling on previous experience (A), using the experience of others (B) and simple honesty (C). I also offered a perfectly reasonable solution in returning a better estimate later, no project is so rushed that you must make an estimate withing 10 seconds and if people try to force you just say “I don’t know, I need to research it” if you don’t know then how can they argue?
Getting your estimate more accurate
Ok you just bought yourself a few hours and you already have reasonable estimates for A and B, but how do you estimate C? You’ve never done it before so where do you start?
Lets pick an example: Writing and running hello world on an android emulator (just assume you’ve never coded android)
After a bit of looking around your going to find out you need to get an IDE, set it up with android, code it, run it. You think it will take 5 hours.
STOP!
Before you rush off with your first instinct lets look a little bit deeper using a 3 point estimate, for this we need to consider the best, expected and worst cases for the task.
Best: You install the IDE and android SDK, follow the guide online, click run and it works - 3 Hours
Expected: This is your gut instinct, that’s the one up above before I screamed stop! This is what you think it will be, not exactly halfway between best and worst. So for our case it will be 5 hours.
Worst: This is where you really have to think, what can go wrong, maybe the IDE can’t be installed, what if the SDK has an issue integrating well and you need to research why, what if the emulator doesn’t deploy properly on your OS. OK you could go on a lot here, probably way too much and sometimes you need to assume things so lets assume the IDE and SDK install as expected but it takes you longer to figure out the code, its only a simple bit of code so it means you take 9 hours in total. Worst case is now 9 hours.
The last step is to turn that into your estimate (math time).
The final thing you need to do is get a 3 point estimate for all of this, that’s pretty easy too its…
(Best + 4 Expected + Worst) / 6
So in our case its
(3 + 4 * 5 + 9) / 6
= 5.4 Hours
Although that may not seem much different, the more risk you have in a task the more it varies the resulting estimate. Using this method you can also monitor the risk attached to any task and compute how likely your estimate is, i.e. I will finish this task in 5.4 hours plus or minus 7% but that is for another day to explain!
Chris
