Till Death Do Us Part

I have posted an article on ProjectConnections regarding how to prioritize your backlog. We're using it and it's working great so far. Check it out.

We were having a problem with focusing on the stories during the standup meeting so we made a simple change. Moving the whiteboard containing the stories to the standup area. Normally this wouldn't be a problem but because the open workspace is not completely finished, we had to make some adjustments.

That was two days ago... So how did it work? Well, in a nutshell, not as good has we had hoped. As I thought about it some more, I think that part of the problem revolves around the fact that we've got a very large agile team, on the order of 20 or so people at each standup. This causes the standups to be incredibly long. We've ranged anywhere from 20-35 minutes a meeting, and that leads to people getting bored and not paying attention. Not to mention standing that long isn't the most fun thing in the world.

I'm thinking of trying something new. With a team this large, it may be better to focus on discussing the status of each of the stories instead of each individual. Doing so may do a better job of focusing the team on the current iteration's deliverables as well as bringing the meeting down to an acceptable timeframe (10-15 minutes). I see one potential problem with this scenario. By focusing on the deliverables more than the team, some of the team members may slip through the cracks, struggling through problem areas without asking for help, therefore adversely impacting team throughput.

After the stand-up today I got to thinking about how there didn't seem to be any focus on what was to be delivered at the end of this iteration; there was just a brain dump of each of the team members' entire day. We then did something drastic. We moved the whiteboard containing our iteration deliverables to the center of the standup, where no one could miss it. We'll see how it works tomorrow...

...and into the fire. I never cared much for distributed planning meetings and was looking forward to having an easier time doing planning when I started my new job... As if it isn't challenging enough, we now have distributed customers and distributed developers. I guess this means I'll earn some good experience with remote collaboration tools.

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.