The Value of Release Planning

In agile, we attack the most important things (those with the highest business value) first. We learn as we go and constantly refine our priorities based on the knowledge gained.

But oftentimes, you need to be able to predict where you're going to end up. You want to know roughly what features are going to make it in the release given the current priorities. This allows you to give stakeholders a feel for where things are going and whether their investment is justified. It allows you to give customers and partners a feel for what is coming their way. Most importantly, this knowledge helps you to make adjustments along the way so that you can ensure that what you end up releasing is best aligned with the needs of the business.

Release planning is a great way to do this. Coming in you need:

• Team structure (who's on what team)
• Team velocities (how many points they can get done in an iteration)
• Release structure (how many iterations, what are the key dates)
• Prioritized and Estimated backlog

Preparing for release planning will tell you a lot in and of itself. It gets everyone on the same page as to who is involved, what the time frames are and what the goals are. In coming up with estimates, you'll identify which stories need to be broken down further / split. You'll also identify which things aren't worth their costs (or need to be split so that only the most important aspects get done).

In release planning itself, each team maps the stories to iterations. The goal is to make it as far down the backlog as possible. So just like it is valuable for individuals within a team to be flexible in the tasks they take on, it is also valuable to be flexible in what stories teams take on. The more you can structure your teams such that stories don't cross team lines, the less complexity you will have to deal with during the release. See this previous blog entry on team structure.

Inevitably, you won't get as far down the backlog as you'd like. At this point, you need to relook at the stories that you have. Are they really the most important? Can you split them so that less valuable aspects can be pushed down the backlog (allowing higher value items to be done earlier)?

This process gets everyone on the same page as to what is likely. But, IT IS NOT A COMMITMENT. It is a projection. Things will change. New items will come up that will be deemed more important. Engineering will discover that some aspects are harder than they expected. Thus, two things to take out of this:

1. Don't commit to the results of release planning. Instead commit to high level themes. We will be working in these areas. How much and what exactly we will do, we will discover as we go.
2. Update the release plan after every iteration. This won't require a full scale release planning. Simply have each team update their projections for future iterations based on the last iteration. And then discuss this / make adjustments based on what you've learned.

Release planning, if done right, can make a huge difference with large teams. If at all possible, make sure the key players are all in one location for release planning. The trust built there will help for the rest of the release.