Agile Release Planning
This content is syndicated from by Kelly Waters. To view the original post in full, click here.
A software release may result from multiple iterations (or 'Sprints' in Scrum).
Sprint Planning is about planning what's included in the next iteration.
Whereas Release Planning is about planning multiple Sprints, in order to predict when a release (or releases) might be delivered.
Release Planning is a very simple way of doing some top-down planning. Much less complex than a more traditional project plan on a Gantt-chart. Therefore much quicker to do. And, I would say, no more or less accurate.
First of all, let's assume you already have your Product Backlog (feature list), with all your User Stories set out in priority order. Let's also assume that you've estimated your product backlog, ideally using Story Points.
If you already have an established team doing Scrum or XP (eXtreme Programming), use the team's known Velocity to divide the Product Backlog into Sprints.
However, if the team is not already using Scrum or XP, you need to estimate the team's Velocity. To do this, you must first make an assumption about the team size that is likely for the release. Then, you need to decide on your Sprint duration and, ideally with the input of the team, decide how many of the initial User Stories you think could reasonably be achieved in a Sprint. Add up the Story Points for these items. Using this number of Story Points as the team's estimated Velocity, divide the Product Backlog into Sprints.
If the project team is not already established, add a 'Sprint Zero' at the beginning to get things ready for the first Sprint, for instance getting the team organised, briefing meetings, setting up development and test environments, preparing the first set of User Stories, etc.
If it's a large or complex release, add a 'Stabilisation Sprint' (or more than one Sprint if appropriate) at the end to stabilise the release. By this, for instance, I mean stop adding new features, complete regression testing, bring the defect count down to an acceptable level, prepare for deployment, etc.
If the predicted end date is not acceptable for the project's objectives, alter the assumption about the team size (and associated costs!) and re-calculate.
And there you have it! A Release Plan that provides an outline of the Sprints, what's included in each, and an estimated date for the release.