The way estimating is done in Agile environments is different from the way it’s done in traditional environments and it can take some time to get right. In this tip, we’ll look at how “points” are used to estimate development efforts and talk about some techniques Agile teams use.
Using story points
Requirements for Agile teams are called stories. A story is a piece of work for the team to get done in an iteration. Iterations are usually two weeks long, but some teams have longer iterations and some have shorter ones. The goal of Agile estimation is to have just enough stories to work on that at the end of the iteration, every story is completely done ("done done"), and the new running, tested features can be released to production.
Agile estimation is accomplished by assigning "points" to stories, and then figuring out how many points the team can accomplish in any given iteration. There are several ways to think about points.
Finally, the number of points that a team can accomplish in an iteration is called "velocity."
Points without time
The classic, traditional approach to assessing the point value of stories is to do so without relating points to any sort of time value. In this approach, points are free-floating units that come to have particular meanings for particular teams. Some teams will consciously avoid any such association by calling their points something funny, like "jelly beans." Usually teams estimate points using Fibonacci values, so a very small story will be one point, a slightly larger one, two points, a slight larger one than that three points, then five points, eight points, 13 points, etc.
Teams just starting out with Agile estimation always estimate badly. Usually for the first iteration the team will take on too much work. Having failed to ship all the stories in the first iteration, the team takes on too little work in the second iteration. This back-and-forth pattern of taking on too many points, then too few, oscillates for a few iterations until the team as a whole gets a sense of which stories are worth how many points, and also of how many points the team can reliably achieve. Over time, these values become quite consistent, and Agile teams using this way of estimating become knowledgeable and reliable as to how many points they can achieve for each iteration.
Points based on time
There are two other ways to think about points that I know of: "ideal hours" and a system based on half-days of work.
A team that estimates using ideal hours thinks, "If we had no meetings, no appointments, no distractions at all, how many hours would it take to finish this story?" The team then tracks how many hours it actually takes to finish the story, and uses that value to measure their velocity. A typical team will have ideal hours estimates that are roughly half of real hours. So a story that is estimated at four hours will often actually take eight hours. It is extremely rare that an agile team, no matter how skilled and practiced, has a ratio of ideal hours to real hours of more than 3:4. That is, even the sharpest and best Agile teams will accomplish only about six hours worth of work in an eight-hour day.
It is worth noting that ideal hours estimates are always wrong. This approach is useful because even though the estimates are always wrong, over time the team's estimates will be wrong in a very consistent way, and the ratio of ideal hours to real hours will be consistent enough to plan the stories for each iteration well.
Another scheme that works well is to estimate stories based on half-days of work. A story that will take only a half day is one point, one that will take a full day is two points, two full days is four points, etc. This approach is similar to the ideal hours approach, but has the benefit of being slightly more accurate overall, but at the cost of being less precise.
In general, it is better to have smaller stories than larger ones. Large stories are often called "epics" and Agile teams will typically decompose or "slice" larger stories into smaller ones.
Mike Cohn of Mountain Goat software has a good example of this at http://www.mountaingoatsoftware.com/topics/user-stories. Cohn's example of an epic is "As a user, I can backup my entire hard drive." He slices this story into any number of smaller stories: "As a power user, I can specify files or folders to backup based on file size, date created, and date modified," "As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved," and so on.
The reason to have smaller stories is that larger stories are more difficult to estimate, and that makes it hard to predict a team's velocity.
I have an example from my own experience that uses half-days, which makes the example easier to think about. On this team, we discovered over time that any story estimated at more than eight points, or four full days of work, was wildly unpredictable as to how long it would actually take to complete. Eventually the team instituted a rule that any story estimated at over eight points was required to be sliced into smaller stories, and those smaller stories estimated separately.
That was a very good team. They had close control over their velocity, and the last I heard of them, they had shipped 35 of the past 38 two-week iterations, and the three they missed were due to things like holidays.
I once knew someone who called himself an "iteration shepherd," and he had a saying that he repeated constantly: "Velocity is a measurement, not a goal."
This means that a team that estimates honestly and always ships running, tested features, will know very closely how much work they can accomplish in an iteration. For example, say that such a team, after time, is confident that they can release 50 points worth of work every two weeks. If management or some other agent requires this team to release 60 points worth of work in an iteration, something will have to slip. The team will take on technical debt, or the features will have lower quality, and morale will suffer.
There is a school of thought in the Agile community that believes that velocity can be increased in a systematic way. This is often called "hyper-velocity." In my opinion, this is a poor way to manage velocity. It does not stand to reason that a team can be forced somehow to increase their velocity indefinitely, or at least not without causing some aspects of the software or of team morale to suffer greatly.
I strongly recommend readers to take to heart that motto: "Velocity is a measurement, not a goal."
Agile teams estimate stories using points of some kind. Over time, the team learns exactly how many points they can finish in each iteration. That number is the team's velocity. Velocity should be an honest measurement of what the team can accomplish.
This scheme is remarkably simple, but also remarkably efficient. However, it takes time and negotiation before a team will evolve to the point that they can be confident in their velocity. Teams just starting out will oscillate between taking on too many points in an iteration and taking on too few, but over the course of many iterations, those oscillations become smaller and smaller, until that team just starting out becomes a great Agile development team.
This was first published in May 2011