Till Death Do Us Part

In an earlier post, I talked about the burndown/burnup chart used in agile processes to report the status of a project. What I like the most about the chart is that it gives you a simple to use and maintain tool for making decisions about your project.

Suppose we are writing a store management system that focuses on bicycle shops. We know that the software needs to be ready in time for its debut at Interbike 2008. There's just one problem, our burndown shows that we won't be ready until November of 2008, nearly two months after the show.

Decision Time

What we have on our hands is a fixed date project. What can we do to bring the date in by two months? When the date doesn't look good on an agile project, there are generally three proposed solutions:

• Add Staff
• Move the release date
• Cut scope

Of the three, adding staff is usually the worst option. Remember Brook's Law:

Adding manpower to a late software project makes it later.

The next option, moving the release date, depends a lot on context. In our example, being ready for the Interbike show provides a major opportunity for securing new business, so we cannot afford to miss the show.

The final option, cutting scope, makes the most sense for us at this time. Having a prioritized backlog allows us to cut out some of the lower priority features in exchange for having a releasable product ready for Interbike.

Now, what happens if you can't cut scope? So we've got a fixed date, fixed scope project. There's no other option right? We need to add staff... I don't think so, there are other options.

Alternative metrics

At the Agile 2007 conference this year I had the pleasure of hearing from Niel Nickolaisen about his Purpose Based Alignment model. By applying his model to the features in your project, you can gain insight about other ways to bring your project's date in to where you need it to be. In the next part of my post on Metrics, I'll take a look at at how you can use Niel's model to help bring in that date.

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.