The Simplest Way to Manage Your Distributed Agile Software Project

Agile Release Planning - A How To Guide

Planning a release for an agile software project is a collaboration between the development team and customer team.

Once you've identified a list of candidate features (in the form of user stories), the development team estimates the relative effort for each, as input for prioritizing. One technique for this high level estimate is to use "points", so that the estimates aren't yet tied to duration (how long it will take), but rather to a relative size (this one is twice as big as that one). You can also use "ideal days" or other time units, taking care not to treat these as accurate durations.

For example, let's create five stories around an online book store. They might look like this:

  • As a customer I want to browse books by category
  • As a customer I want to search books by title
  • As a customer I want to search books by author
  • As a customer I want to buy a book with a credit card
  • As an administrator, I want to add books to the store
Now, the development team assigns high-level estimates in points. They believe that the search-related stories are about the same size (2 points), the "browse" story is twice as difficult as those (4 points), the "buy" story is significantly harder (8 points), and the administrative story is about as hard as the browse story (4 points).

After being assigned estimates by the development team, the stories might look like this (as shown in the Release Plan view of ExtremePlanner):

To plan the release then, you start with the expected capacity (or velocity) of the team. How much can we do (based on how much we did in the past)? If you completed 10 points during the last release, then that can be the starting point for planning this one. For the initial release, it's best to be conservative, since you can always add more functionality if the first few iterations show that you can get more done than you thought.

Next, you'll need to prioritize the set of estimated stories. It's not necessary to prioritize every story at this point, just enough to know that the most important things will be worked on in the first release.

You prioritize based on the business value of the story, as well as the developer estimate. The process is similar to grocery shopping with a limited budget. You have a shopping list, the items in the store have prices, and you know what's most important to you (maybe some meats, vegetables, and bread), what's more of a luxury (chocolate chip cookies), and what you can get later (the latest issue of a tabloid gossip magazine).

Similarly, you'll choose stories to fill the release, limited by the total capacity that the team can handle.

Release Planning With ExtremePlanner

In ExtremePlanner, the release planning process is supported by the Release Planner view. You can drag and drop stories from the backlog to the release plan, which will automatically update the total effort scheduled so far and alert you if the capacity is exceeded.

You can try out different combinations of stories to fill your release capacity. It might make more sense, for example, to schedule 2 or 3 smaller stories of less importance instead of a single larger, slightly more important story. The Release Planner let's you try out these scenarios until you've reached a stable point.

[ Click for More Resources ]


Copyright © 2004-2010, ExtremePlanner Software. All Rights reserved.