5 Simple Ways To Get More Accurate Estimates

July 13, 2015 - Marco Behler

Ugh. Your boss wants an estimate for a couple of new features that your client requested. Problem is, your last estimates were way too optimistic and far off the actual time needed. Talk about deadline pressure, eh? Here are 5 simple ways to not make those same estimation mistakes again.

1. Poor man's land: Padding by gut feeling

The simplest and most common way to improve your estimates is by applying a "gut" deviation factor to your estimates. Unless you have a track record of estimating overly conservately, most mistakes are actually made by being too optimistic and hence estimating task durations way too short.

For a long while I personally multiplied my estimates by 1.5x my original estimate: Say I thought that adding that new webservice XYZ is going to take 6hrs. I usually found it would be safer to go with 9hrs (1.5x), because I consistently underestimated the task's complexity - over overestimated my abilities.

How do you come up with that number? The poor man's version: You simply pick one between 1.0 and 3.0 that feels right. Yep, you read that right.

2. Simple Time tracking

But randomly chosing that number from your gut is also sub-optimal. The next improvement would be to actually track/write down your estimates and actual time spent over a period of one or two months. Almost no problem if your
company already uses some sort of bug/time-tracking tool like Jira or Youtrack and you have to track your times.

You then simply generate a report with 3 columns: All your estimates summed up over the last two-months (567hours), all your actual hours spent (1024hours) and then your actual hours divided by the estimated hours = 1.8x. Voila!

3. Advanced Time Tracking

Simply adding together hours in Jira leaves out the context of the work being estimated. Maybe you are actually quite accurate estimating a certain group of tasks, say programming financial rules, maybe you have more difficulty with others, say deployments of your software. And wouldn't it be nice to look at estimations of past, similar tasks for your new estimates?

If you tag your tasks/user stories in Jira you can simply export all your actual/estimate values in a report by tag name. Then calculate different deviation factors. And also use those related, past tasks as reference for your new estimates.

4. Most importantly: Work those requirements

All of this does not help, if you do not take the proper time to deconstruct your requirements and generate a highly accurate and mutual understanding of what exactly needs to be done between business and programmers. And yep, the importance of this is often completely neglected. Having a boring planning meeting != understanding.

Remember the old saying: How do you eat an elephant? Piece by piece. Same with software estimates. Do not make the mistake of blindly estimating the whole elephant in the room. You can learn how (not) to do this and much more in my book on customer requirements.

5. Build Spikes

Unfortunately big parts of the "agile world" would rather play planning poker and estimation games for countless hours than taking the time for 30 minutes to build a small and simple spike version of your actual task ahead. Often a spike is the only meaningful way to approach bigger or technically fuzzier tasks and give proper estimates.

Do not let your colleagues convince you that spikes are only for the trash-can and hence a waste of time and you should quickly estimate an unkown task with story points instead. Au contraire.

Summary

Estimations are often handled as some sort of fuzzy event where you sit together with your colleagues, look woefully strained for a couple of seconds and then suddenly a magic number pops up. No wonder these estimates are unreliable and the complaints are high.

Use the techniques above and you will see your estimates getting much more accurate over time.