Release Planning doesn't have to be a painful multi-day meeting. Certainly, your first few release planning meetings take a while as the team gets used to one another. But after your first release, it is often feasible to cut your release planning meeting down to a half day, or even a few hours. Here are some tips that can help?

Stay focused

Why do we do release planning? So we can commit to delivering on a release goal by a certain date. In order to do this, we need to know what's driving the date, what the goal means, and how much work goes into satisfying the goal. We don't need to know the gory details of every single feature. We don't need to talk about features that are part of future releases. We don't need to break stories into technical tasks. We just need to know what it means to "Enable online claim submission", and whether or not we think it's feasible to deliver some form of that goal that satisfies the customer by May 1st. We're not committing to the exact details.

Know the goal

As a team, we've got to be clear on what's motivating this release date. Have we promised something to a customer by that date? Do we have a regulatory date we need to meet? Is there a marketing event or trade show? Did someone make a commitment to upper management? The team needs to know where the date is coming from, so they can help get the best possible scope completed by that date.

Do some advance preparation

Come in to the meeting with a prioritized list of user stories. If you've got time, get a developer or two to look at the stories in advance, so you know whether they're sized appropriately (most should be a half-iteration or less in size) and if there are big questions about those stories. Get your priorities straight before release planning; have a good sense of which stories are

• Must haves: there's no point in doing this release without these features
• Should haves: some customers won't accept this release without these features
• Want to have: It's harder to sell this release without these features

If you've got bad stories, or they're not prioritized, you'll waste a lot of time in an expensive meeting hashing out the details. The major goal of release planning is to get everyone on the same page and then commit to a release; this goes much faster if you've done some preparation.

Estimate relative size

Mike Cohn says a skilled team can estimate relative size of 20 stories per hour. In his Agile Estimating and Planning book, Mike presents some good techniques for learning to do this fast. You're not estimating duration, just how hard each story is to implement, and how much of it there is. If Story A is a 5, and story B is a 3, we can count up how many points our team gets done each iteration and use this empirical evidence to predict how many points we'll finish in the 4 iterations before our release. It's a really simple approach that's really powerful and can save hours, days, or weeks of estimation.

Watch out for too much detail

You don't need to work out all the details for each story to do release planning. You want to document key assumptions, but this should only take a minute or so per story. This is not the time for creating technical tasks or detailed estimates; you'll do that in iteration planning.

Any other thoughts for how to speed release planning? Post a comment; I'd love to hear them.