Estimating Duration (or how long will this take?)
One of the biggest aspects of any project is estimating how much time a given task, and in combination the whole project will take to develop. Scrum provides a mechanism for estimating work, but converting them into duration can be very difficult. This post will discuss my experience in managing large projects, and the estimation mechanism I have developed, based on story points, to cater for these situations.
There are 4 factors that are considered to accurately estimate duration. Work estimate, staff overhead, client overhead, estimate accuracy.
Work Estimate
All features should be assigned as estimated effort, or cost, to implement. Unlike Agile story points, these costs are an indicative idea of how much time development will take in an ideal world. By this we mean 1 developer working continuously, with no disruption, at peak efficiency. We use a modified Fibonacci series, such as 1, 2, 3, 5, 8, 13, 20, 40, and 100, to represent effort (as used in many popular planning poker cards). This encourages features to be split into the smallest task possible, and provides a more realistic estimate range. To ensure continuous improvement for estimates, developers should be responsible for the estimation. We can estimate features in 4 different ways, and once again people who use Story Points should find this familiar.
- Expert opinion: The team member with specific understanding, or who is most likely to develop the task, can provide a more accurate estimate of effort. e.g. A database administrator can better estimate effort for database tasks.
- Comparison: Comparing a task to another, already estimated, task. e.g. "Task A is about twice the effort of Task B"
- Components: If a task is too large to accurately estimate, break it into small sub-tasks. e.g. User management can be broken into interface, login, access control, etc.
- Planning Poker as developed by James Grenning: If using Planning Poker, estimates must not be mentioned at all during discussion to avoid anchoring. A timer may be used to ensure that discussion is structured; any person may turn over the timer and when it runs out all discussion must cease and a round of poker is played.
- Each person lays a card face down representing their estimate of the task, and then simultaneously turns their cards over.
- People with high estimates and low estimates are given an opportunity to discuss their estimate before anyone else can speak.
- Repeat the estimation process until a consensus is reached.
Estimate Accuracy
We know that some tasks are more complex than others, so to represent the unknown and to provide a level of flexibility into the estimates, we assign a accuracy percentile modifier. This is a percentage between 0% and 100% which is multiplied to the estimate itself (strictly speaking the modifier plus 1).
Customer Overhead (optional):
This is a percentile modifier relating to the difficulty of customer, and is calculated once, at the beginning of the project. I'm sure we have all projects where if the client was not involved would have been finished much sooner. :-) If you do not have a client, or only one client then the modifier is 0. Extreme clients, who continuously interrupt and interfere are given a modifier of 1 (or 100%). You can consider this as a client who doubles to amount of time it takes to complete a feature.
Staff Overhead
This is another percentile modifier relating to time spent by staff, not working on the project. This includes unplanned leave, illness, illness, regular breaks, meetings etc. This should be calculated before each iteration by dividing the total number of work hours in the iteration by the number of hours spent working on the project in the iteration (which you should be capturing in your workload management system like trac).
e.g. Given an iteration of 1 week (40 hours) and 4 staff (Jenny, Tobias, Ashley and Andy). For this example, assume Jenny and Andy have planned leave for 1 day (2 x 8 hours) during this iteration. In the previous iteration you recorded that Jenny spent 30 hours, Tobias was ill and only spent 22 hours, Ashley spent 35 hours and Andy spent 31 hours working on the project.
Total hours = (4 x 40) – (2 x 8) = 160 – 16 = 144 hours
Work hours = (30 + 22 + 35 + 31) = 118 hours
Overhead = 144 / 118 = 1.22 (22% overhead)
If you don't have this number for your first iteration, try 25%. That's about average for most dedicated ICT project staff.
The Calculation
So, how does this all come together. Our team is given a task description and they estimate it will take 4 ideal hours to complete, plus or minus 20%. In this example we assume that the client has been assigned a modifier rating of 10%. So;
estimate * (1 + client overhead) * (1 + staff overhead) < Duration < estimate * (1 + accuracy) * (1 + client overhead) * (1 + staff overhead)
4 * (1 + 10%) + (1 + 22%) < Duration < 4 * (1 + 20%) + (1 + 10%) + (1 + 22%)
4 * 1.1 * 1.22 < Duration < 4 * 1.2 * 1.1 * 1.22
5.37 < Duration < 6.44
This means that the team estimates that the assigned task will take between 5 ½ and 6 ½ real hours to complete. Always round, 5.37 hours is a ridiculous estimate and your boss will look at you funny if you say that.
Improving Estimates
I often get asked, won't the team always over estimate to give them more time? And the answer is, no, it is not in their interest. Each piece of work will be estimated and then the time taken to implement it will be recorded. This builds an estimation feedback loop, where staff will be in a continuous cycle of estimating, developing, and reviewing the estimate against the actual.
It is often for this reason alone, I recommend Agile development to most of my employers. In a traditional waterfall project, there is no opportunity to improve and refine your estimates as the project continues.
Attribution
Image is public domain via Wikimedia