Release Planning

The first thing you need for release planning is a prioritized backlog.  You should really have this at any point in time, but in the beginning particularly, you might not.  Now is a good time to discuss the backlog as a team to ensure you're all on the same page with the priorities.

Next, each team should have a velocity for the release.  Think high level.  People iterations are useful.  So if you have 5 people and 6 iterations to add features, than you have 30 people iterations of velocity for the release.

Each team will likely have areas that they have traditionally owned.  For each team, have them put high level estimates for each feature based on those areas (going down the list in priority order).  Stop when the team runs out of velocity.

As an aside, we often focus on the developers.  We ensure that QA and doc are present in the right ratios.  But to keep things simple we often don't estimate those independently.

Now a few things should be obvious.  Based on traditional ownership, some teams made it further down the backlog than others.  Look for opportunities for cross training / changing ownership so that you're optimized to make it as far down the list as possible.  Also useful is if you can reduce the number of teams that need to participate in each feature.

Now that you've done some load balancing, start thinking in more detail about what needs to be done to accomplish those features.  In other words, how are you going to break the feature into increments, each of which add customer value?  This can take a week or two given everything else you likely have going on.  If it takes longer, you're probably over thinking it.

By the way, in person is much better.  If your teams are distributed and you're able to spend for travel, release planning is the time to do it.  Consider bringing in the participants for the full week leading up to release planning.

For the release planning meeting itself, allocate a full day.  Start off for an hour or so and make sure you're all on the same page with the priorities for the release and the objectives for the day.

Break out into the individual teams.  Each team maps their cards (each increment goes on a card along with its cost in number of people) to the iterations.  Start with the highest priority card in the first iteration.  Move to iteration 2 when you've used up your velocity, etc.  The really interesting part is looking at the other teams.  Adjust to make sure that you're in synch.

At the end, go through each iteration.  Each team says what they're hoping to accomplish for the iteration.  Other teams ask questions and bring up issues or concerns.  The net result after you've gone through all of the iterations: everyone has a good feel for what you're trying to take on in the release.

This is not a commitment.  Individual estimates might be way off.  Priorities will change every two weeks.  But you start off on the same page and by staying in touch, you can remain there.  More on that later.