Agile Metrics Part 1
We've been discussing various metrics for planning and decision making in Agile projects as of late and here I plan on mentioning a couple. In subsequent posts, I'll try to clarify some more of what my current thoughts are when it comes to backlog management.
The Basics
Metric 1: Technical Velocity
It is fairly standard practice in Agile projects for a team to track their current velocity using the Yesterday's Weather method. If a development team completed 35 story points (or ideal days) last iteration, it will use that as its projection for remaining iterations. At first this metric tends to be a bit unstable, however the velocity tends to stabilize over time, making it a fairly accurate measurement of progress.
Tool 1: The Burndown Chart
The burndown chart is a way of visualizing your velocity with an eye towards your project end date. The idea is simple, take the number of story points remaining on the project backlog on the Y axis and time on the X axis. By graphing the remaining effort to date, you will have a (hopefully) downward sloping line that can be utilized in conjunction with projected velocity to arrive at an end date. Mike Cohn has an example here.
I like the burndown chart, but it does have one flaw: It shows the points remaining at any given point in time, but id does not show the variation in total points as well. I feel that when you have a fair amount of requirements churn the burnup chart has the edge.
Tool 2: The Burnup Chart
The burnup chart uses the same X and Y axis of the burndown chart, but instead tracks two sets of data. The first is total project effort required, and the second is the total points completed to date.
In this case, I also choose to use the concept of Yesterday's Weather as applied to scope increases. This allows us to more accurately project the end based on the assumption that additional scope will be added throughout the life of the project. The project's projected end date is the date at which the two lines converge.
Now that we have our velocity and projected end date (updated every two weeks), we can start to make some decisions based on our projected end dates. In the next post I will discuss the typical tradeoffs made on an Agile projects and a couple others I've been thinking about.