XP and Earned Value

Iterative planning is great. In fact, I think it’s one of the best parts of XP. As a team, we struggled when planning in the large. Looking ahead further than about a month was difficult for us mostly because the world changed drastically as soon as we started working in it. Once the rubber hit the road our idealized plans were rendered useless within in days, sometimes within hours. Why bother looking past what you can’t reasonably anticipate?

Seeing far into the future with great detail can be tough but XP’s "build only what is needed today" attitude keeps plans from getting too out of hand. With stable enough requirements and a solid architecture in place it’s relatively easy to figure out what needs to be done within a short (in our case, two weeks) iteration to meet the team’s commitments. Much more difficult is knowing how the project is progressing within the total scope of everything that needs to get done.

XP works well with pay-as-you-go style contracts. It’s a natural fit. From the development team’s perspective, the idea is to provide as much value as possible for the customer as early as it makes sense for the project. The Studio Project is very much a fixed time/cost project - we graduate in December and additional students can’t be "hired" for our project. Scope (and quality) is the only remaining negotiable software element. Though scope can be negotiated, the customer still has an idea of success in terms of the sorts of features that she needs in her software. Since we can’t extend our deadline or hire additional programmers, understanding exactly where we are in the project and how much work remains is critical.

This is where earned value analysis comes into play.

As it turns out, earned value analysis and XP can work together. The trick is understanding how the scope can change, what needs to be fixed and by when, and modifying the standard earned value graph to show the current progress in a more volatile planning environment. To use earned value within the XP environment, we made the two changes, one to XP and one to the earned value graph.

• Make commitments for two iterations at a time but only plan the next iteration in detail. For this to work, the team has to be willing to change commitments for the following iteration based on how the next iteration was executed.


• Add a new line, the "Projected Planned Value," which is based on the known amount of work remaining. Treat this line as an extension of the standard Planned Value line.

The result looks something like this (click on the image for an animated demo!):



We found that XP and earned value complemented one another quite effectively. We used burndown and the planning game for iteration planning-in-the-small and earned value to get a better feel of where we were in the larger context, when (and whether) we would actually finish the project.