Agile estimation is an accurate and reliable way to plan and release software projects. And yet it is still poorly understood by many software teams. Insights from real working agile teams will help illustrate how agile estimation works.
Before discussing agile estimation,
- Unit test coverage. Test driven development (TDD) is an excellent way to achieve a high degree of unit test coverage, but other ways exist.
- Institutional code review. Pair programming is an excellent way to implement code review, but other ways exist.
- Continuous integration. It is necessary to run the build after every commit to the code base.
Stories and points
Software projects have requirements. For agile teams, the requirements are called "stories." Before the project starts, the whole team must gather together and assign a point value to each story. The estimation will be based on the points assigned to the story. It is important to assign points to all of the stories at the same time. Even if the points are wrong, when the points are consistently wrong, then agile estimation still works. Assigning points to all the stories at one time helps ensure that the points will be assigned consistently.
The agile literature emphasizes that points are arbitrary values, but in practice many teams relate points to time in some way. One team I know says that one point is about a half day's work. Another team I know says that one point is about an hour's work. Another team I know describes points in terms of "ideal days"; the amount of work to finish the story assuming no meetings, no breaks, etc. Other teams I know of insist that points are purely arbitrary and have no relation to time. Ultimately it does not matter how the team conceives of their points, as long as the points are assigned to stories consistently. A two-point story should take about twice as long to complete as a one-point story.
The first few iterations
The collection of stories to be implemented is known as the "backlog." Agile teams typically handle the backlog in one of two ways. Some projects collect all of the stories for the whole project in advance, and estimate them all at once. This approach is particularly useful when the release date for the software is critical, and it is the example I will be using. Another approach is to collect only enough stories for each iteration and estimate only that iteration's stories. This approach is particularly useful for ongoing maintenance of an existing application.
In this example, the whole project has been estimated and all the stories combined add up to 1000 points. The Customer or Product Owner specifies the most important stories for the iteration, and the team agrees to take on 20 points for the iteration. At that moment we can estimate that the entire project will take 50 iterations.
But on the first iteration the team only delivers 10 points of the 20. At this point we can estimate that the entire project will take 100 iterations.
This is a new team on a new project, and unexpected things happened during the first iteration that made it impossible to deliver the full 20 points. Now much more cautious, the team agrees to deliver 10 points for the second iteration, just as they did for the first. However, they learned from their mistakes, and on the second iteration they deliver 15 points. At this point the team has delivered 25 points in two iterations, so we can estimate that the entire project will take 80 iterations. (The practice of basing the current estimates on the previous few iterations is called "yesterday's weather.")
This pattern of starting out by estimating too many points for one iteration and then too few points for the next iteration is so common on new agile teams that it is likely universal. Over time, the fluctuations even out and the estimates get more accurate. Note though, that if the team is disturbed in some way, for instance by replacing some members or by adding new members, the fluctuations in estimate accuracy will return. Making big changes to an agile team forces the team to re-negotiate how they work together, and that negotiation has an effect on the accuracy of the team's estimations.
Most agile teams make a graph of the points accomplished for each iteration publicly available to everyone on the team. Such a graph is called a "burndown chart." In the example above, there would be a line starting at 1000 in the top left, leading gradually down to zero at the bottom right. Along the bottom of the chart is a calendar. After every iteration, the line connecting the points accomplished for the past iterations indicates a particular date when the project will be finished.
The number of points accomplished per iteration is called "velocity." I once worked with someone who told me "velocity is a measurement, not a goal." The Agile Manifesto says "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely" It is important to understand that the team is doing their best work, and it may turn out that the team can happily and sustainably deliver 15 points per iteration. If management requires them to deliver 20 points per iteration, then something will eventually go wrong. People will tire and become slower, or technical debt will run out of control, bringing the project to a halt. It is worth repeating: velocity is a measurement, not a goal. There are a number of ways to increase velocity, from making the team larger to reducing outside interference on the team, but to simply require higher velocity than the team can sustain is not a useful approach.
The most important thing to remember about agile estimation is that it works in the long term and not in the short term. The original assignment of points to stories is probably wildly inaccurate and should not be used for project planning. The team's estimation of its own velocity starts out wildly inaccurate and becomes more accurate as the team refines how they work together.
It is the real, empirical measurement of actual velocity over time that makes agile estimation so useful. Mastering agile estimation gives teams and managers the ability to know not only how much the team can accomplish for each iteration, but also gives them the ability to do accurate long-term planning, even on large projects.
About the author: Chris McMahon is a software tester and former professional bass player. His
background in software testing is both deep and wide, having tested systems from mainframes to web
apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris
has been part of the greater public software testing community since about 2004, both writing about
the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent
work has been to start the process of prying software development from the cold, dead hands of
manufacturing and engineering into the warm light of artistic performance. A dedicated agile
telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S.
Luckily, he has email: firstname.lastname@example.org.
This was first published in July 2010