The Agile estimation sheet

The usual agile estimation guidelines that you will find on the net are about gambling an estimate with your entire team. The goal of these kinds of ‘estimates’ is to get all knowledge that is available in the team into the estimate. Usually this should work pretty well, in practice we know that all estimates of software developers are generally way too optimistic.

Misplaced optimism

Developers are optimists by nature and most estimates are based upon the assumption that something will actually work once it has been coded.

This is not realistic as many first attempts at implementations are undermined by imperfect understanding. It’s only when you attempt to code and execute something that you uncover the weaknesses in your understanding of the problem and underlying approach to a solution. This creates bugs and delays.

Even the best estimates where work items are estimated in small chunks have this problem.

How to improve our estimates?

So how can we overcome this problem? One thing we can do is ask the software engineers, that work on the project, to re-estimate after some amount of work has been done. The benefit here is that knowledge has been gained during the project meaning that we will have a better understanding about the work items that are still remaining to be done.

We use the “remaining workload sheet” for this. The idea here is that every so often, suppose every week, software developers update the sheet with a new estimate of the, remaining workload. Please note that engineers are allowed to change the estimate by adding more work items (that were previously not accounted for) or delete work items, although that unfortunately does not happen that often.

Here is an example sheet how the remaining workload sheet or Agile estimation sheet might look like after a few weeks of work.

Nice sheet, but what do I see here?

This example uses ‘workhours’ as estimate, so the first estimate of the entire workload for this particular imaginative project is 82 hours. After one week of work, it turns out that all workitems for developer A are still exactly the same as when we estimated a week ago. For whatever reason, we can see that task B2 apparently is a much harder task than was first estimated. We thought it would take a day to finish this task, but after a morning (or afternoon) of work, we have a new remaining estimate of 8 hours, meaning that the total time of task B2 has raised to 12 hours, meaning we are losing 6 hours on the first estimate we made. This is something that is very likely to occur in software development.

After the project finished, we see that 92 hours were spent instead of the earlier estimate of 82 hours. Pretty ideal situation. BTW: Above I explained where we needed six extra hours. In total we needed ten extra hours. Can you see on what task the other four hours that we eventuelly needed to fnish this project were spent? If you can’t, let me know. If you can see it, you have found a new estimation tool at your disposal that you can use in your very own projects. Good luck, code warrior, and may the green forces be with you.