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.
Prerequisites
Before discussing agile
estimation,
Requires Free Membership to View
it is important to have good development practices in place. If the software is a
constant source of unpleasant surprises, no method of estimation, agile or otherwise, will succeed.
In particular, three things need to be in place before agile estimation will be valuable:- 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.
Velocity
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.
Agile estimation
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: christopher.mcmahon@gmail.com.
This was first published in July 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation