One Useful Agile Method For Project Estimations

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:

Absolute estimation
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.

Relative estimation
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.

6 thoughts on “One Useful Agile Method For Project Estimations

  1. What I’ve found useful is to:

    1) First ask the client’s budget
    2) …and then tell what he can get for that price*

    Saves everybody’s time.

    * (after careful estimation based on your past experience, uncertainty of the projects, splitting it in tasks and other factors)

  2. That’s an interesting way of tackling it.
    I’d found that estimating x2 was reasonably acurate, perhaps I should adopt x3 in future to ensure I’m always under budget?
    None of this really works when prepping a quote for a new client though. If you were to quote x3 to a client, they’d most likely say “How much!!???” and go elsewhere. If you adobted this agile method, you’d have to quote them your first estimate, then come back to them at some point down the line with the revised actual (x3) estimate. There’s no way they’d be happy with that setup. I guess it works better having got it wrong a few times first?

  3. x3 has always worked for me too, but with experience I’ve started being able to estimate x2.5 :D

    Agile development : When it works, it works great. When it doesn’t work …it’s probably being done wrong because the manager didn’t understand it properly …but he still swears by it.

  4. I agree with Josh. Follow the law of PI: multiply by 3.14 and you will be OK.

  5. Yeah, makes sense. Although I don’t call such relative units points; I just call them units.

    Or I take the estimated number of months x 2. School and sports slow down my work rate a lot too. :)

  6. My formula is this:

    Time if everything goes smoothly X 3 = actual time

    And I am usually early!