I’ve done (IT/games) project work for almost a decade, and one of the trickiest thing has been (accurate) work time estimations. I’ve been participating in doing estimates for small and big projects, and sometimes there has been more time to do these estimates, sometimes less time.
It’s a tough job
It has been quite typical that in a long run, estimates are really tough to do very well. If you give estimates in “how many hours it will take”, it feels like there’s always something that might be missed. Sometimes there might be new bugs appear that take time. Or, the code maintenance gets trickier. Or something else.
Agile methods help
One useful approach for this comes from agile methods. I think any team (whether they have interest in agile methods or not) can use this system for better estimations.
The idea is to use relative size estimations, not absolute size
It’s been suggested that it’s easier to estimate relative sizes instead of absolute sizes. Instead of saying that finishing certain task A will take 3 days and task B takes 6 days, you could say that task A will take 3 points worth time, and task B will be approximately double of work, or 6 points.
Take a look at the following picture:
How many proper blue and red poker chips there are? In this case could go through them one by one and say the number but it would take time and you might still make a calculation error, or some of those blue chips could be damaged and should not be taken into account. Some of them could be missing from the picture. If you want to know the absolute number of blue chips, it would take you some time and the number could still be inaccurate. Same goes for red chips. Or black. Or green. Or whatever colored chips there might be. You’d be counting the chips all day, and still make errors.
Now, how many blue and red poker chips there are if you use relative estimation? You could say that there’s about half (+50%) as much red chips as there’s blue chips (for example, you could say “10 points worth blue chips, and 15 points worth red chips”). Of course you could wonder if there’s more of those black chips (and take a better look and ask others) and say for example that there’s 13 points worth red chips if you feel that way.
Again there could be some broken blue or red chips, but if we are measuring the relative size it has lesser impact. If for every 2 broken blue chips there’s 3 broken red chips, our estimate would still be correct. If on the other hand we see that there’s more broken blue chips compared to other type of chips we can re-estimate the points for the blue chips for example.
Back to game development: The idea is not to know how many hours one task will take. The key idea is to establish a common baseline for making evaluations (as in “this task takes 2 points, this one 1 point, and this one here feels 3 times bigger than the previous 1 point task so let’s call it 3 points task”) and use points instead of hours.
Getting to hours
But what if you want to know how much time it takes? Patience grasshopper.
The ‘how many hours it takes’ will come from experience. The goal is to keep estimating using points, and then track your progress as time goes on. After some time, you will be able to say that “okay, I spent 200 hours doing this, and finished 10 points worth of features. From this I can say that 1 point – in a long run – is approximately 20 hours of work.”
Let’s take an example:
This can be useful also when taking into account bug fixing. Let’s suppose you’ve estimated that coding a module takes one week. You finish the module in 5 days and are happy with the results. The bad news are that in the next week you spend 2 days fixing unexpected bugs that were found by the testers. Also, one more day is spent reviewing and refactoring the code since there were some problem areas that needed bit more work. That means the estimated module took 8 days instead of 5. The last 2 days you spend coding some other smaller module that was estimated to last 1 day.
With a points system you could have said that the first task takes 5 points (for example), and that the other smaller task takes 1 point. Your estimate is bit off (since the first task took 8 days, and the other 2 days – which means the relative sizes are 4:1.) but you can’t always know exactly how many points something takes and you can trust that this number gets better as time passes.
After a few more weeks, you could give a pretty accurate number that on average you managed to finish 6 points worth in two weeks, which means you’d have basis for evaluating how much work you can do.
The more I’ve been using this type of estimation, the better I feel about it.
For those of you who are interested in agile methods, I suggest reading Mike Cohn’s blog (and his books). He has plenty of good information on how to use agile methods.