The following is an adaptation of content I wrote to help a new agile team. It was meant to be a brief skim over the surface of estimation, rather than an exhaustive document. It generally sticks to the classical agile approach, but has some additional techniques that I have found useful. The information on which this is based is largely attributable to Mike Cohn, of Mountain Goat Software, perhaps my favourite technical author of all time and, for me, certainly one of the most readable. I would love to hear peoples opinions on estimation, feel free to drop me a line with any tools and techniques that you use.
Story Points
It is very difficult to provide an off the cuff estimate for something unknown. We may hazard a guess or try and compare it to something else of similar or relative size. If asked to estimate the size of a mountain, it would be much easier to estimate it as double the size of another mountain than to specify a weight in kilograms. There is also significant scientific evidence to support the hypothesis than humans are much better at estimating relatively than absolutely.
Story points are way of estimating effort to complete a feature that decouples that tie to specific units of measurement, such as time. By estimating effort in relation to other estimates, we can derive a value for time. Because we have estimated relatively, our final value for time is likely to be more accurate.
A story point is a unit independent measurement of effort required to complete something. Features are measured in a number of story points.
A useful video by Mike Cohn discussing User Stories can be found here: http://www.youtube.com/watch?v=6q5-cVeNjCE.
Velocity
Now, as we are estimating in story points and not time, we need a method of estimating how much work we can to in a given time in order to derive schedule estimates. This is where we use velocity. velocity is the amount of story points that can be completed in a given time, usually an iteration. A velocity of 8 means that for the current iteration size (We will use 2 weeks), you can complete 8 story points worth of work. 8 points for every 2 weeks. This means that 24 points of work (A 24 point project) will take approximately 3 iterations, or 6 weeks.
Because the features are estimated in relation to each other, should the velocity change, the schedule is self correcting. If the projected velocity drops to 6 points, we do not need to reschedule and plan everything. It will now simply take 24/6 iterations (4), or 8 weeks.
Note that velocity is the measure of a team, not an individual.
Techniques for Estimating
Sharing
A benefit of story points is that they are independent of the person. The amount of work required to complete a task is the same for each team member who may accomplish it. I may take an extra 5 hours to complete something than you do, but it doesn’t need to be factored into the estimate. This means that although you are the more likely person to be completing the task, should you be unable take it on, I can complete the work without having any effect on our original estimation. This separates the person/task link, which further aids in team cohesion.
Scale
The larger a story is, the less likely that you will be able to estimate it accurately. To ensure that we do not give a false impression of accuracy, an estimate must fall into one of a sequence of buckets. The estimate must be less than the maximum size of the bucket you are trying to fill and the difference in bucket sizes grows. This ensures that you do not give a false impression of accuracy for larger tasks. A good scale to use is the Fibonacci sequence: 1, 2, 3, 5, 8 as the growth in bucket size reflects the uncertain nature of larger estimates and gives a good level of precision for smaller stories. To be clear, you cannot put a task in a bucket that does not have enough space. Even if it is very close, 6 will never fit in 5, so must be put in 8.
Expert Opinion
One of the quickest ways to get an estimate for an item is to ask an expert. Here, expert could simply be someone who has domain knowledge or someone who has done something similar previously. It is difficult to always find an expert and care should be taken not to offload the estimation responsibility to others.
Analogy
This is where you simply reference the size of other items in order to determine a relative estimate. For example: “I believe this is a little bigger than that 4 point item”, “I think that this is approximately twice as big as that 2 point feature”.
Disaggregation
Some stories may be quite large because there is a large degree of uncertainty or the development of that feature is far off and does not require detailing yet. For these items, it can be useful to split story and estimate the constitute parts. This does not mean that you are physically dividing the story, merely breaking it down mentally in order get a better estimate of size using one of the other techniques. It is very difficult to try and estimate if a story is 100 times larger than another one.
PERT
A useful technique when you have no previous evidence or advice available is to use PERT. This tasks a weighted average of several possibilities in order to generate a more balanced guess. The formula is: (P + 4M + O)/6, where P is the most pessimistic estimate, O is the most optimistic and M is your best guess, or most likely. For example, I am estimating a task and don’t have previous experience, empirical evidence of expert opinion. My best guess is that is will take 3 points of effort, I think that if everything goes wrong it could take as much as 8, but if everything goes really well and it’s easier than I thought, it could be only 2. The formula for this is (2 + (4*3) + 8)/6, or 4.67. This means that it should go in the 5 point category.
Re-Estimating
Completed stories should never be re-estimated.as this artificially modifies your velocity. If a task is more difficult than you thought and was actually 5 points instead of 3, changing it to a 5 means that your velocity was higher and will be committing to a greater number of points for the next iteration. However, it is likely that you will also need to update the estimates for tasks in the backlog, which raises the amount of work to do by an appropriate amount. You are now in exactly the same situation as you were previously. If, however, you only update future tasks then your velocity remains the same, but the work to be completed increases. This means the overall effort to complete the release has increased, which will be reflected in the schedule. There will also be tasks that take less time, this fluctuation generally balances out. Velocity is self correcting and averages out over times, we are not overly concerned with specific iteration velocity, only the average velocity over the project.
Getting Credit
Do not be tempted to give partial credit for partly completed features. You may believe that you are 90% done and should therefore get 90% of a point, but you are then working with a false sense of precision and cannot guarantee how much there is actually left. Something may come up in that last 10% than increases the work required by a factor of 2, or 3. Even if you have done 99% of the work, unless it is accepted, it is not completed. These variations balance out over time anyway, do not be overly concerned with the velocity reflecting how hard you have worked. It is an estimation of work left to completion, not a persons drive or KPI.
When to Estimate
Release Planning
During initiation, any stories that may be included in the release should be estimated to a reasonable level so that the sponsor can effectively determine the priority. These stories will estimated by asking questions of the customer or sponsor until the team have a good enough understanding of the requirements until such time that they feel that they can appropriately make an estimate. It is important to note that estimates are not guesses, they are educated and based on at least one of the criteria discussed previously. If you feel like you cannot make an estimate at this time, do not be tempted to guess; instead, schedule a spike or consider one of the techniques outlined above. All relevant stakeholders should be present during this meeting.
Iteration Planning
Prior to launching an iteration, all relevant stakeholders should meet in order to determine a plan. During this time, the iteration will be filled with stories. Is is important to revisit the backlog at this point and estimate or re-estimate any stories that may potentially be included in the iteration. The format and process is the same as that of the release plan, but will only be focussed on the following iteration.
During iteration planning, the selected stories will also be broken down into technical tasks (but not necessarily assigned). These technical tasks should also be estimated, but in terms of hours required for completion. At this level of detail, it is appropriate to use hours as a unit of measurement as the understanding should be very high and it provides a greater level of granularity for team members planning their personal day or week task list.
Iteration Review
Following the completion of an iteration, any new knowledge gathered regarding estimations can be fed back into the remaining issues. Now is an appropriate time to update any estimations.
For more information on estimating, Agile Estimating and Planning by Mike Cohn is an absolute triumph and well worth a read.