Release Planning
Release planning is the continuous process of defining, splitting and prioritizing the stories in the release backlog. The agile approach assumes there will be changes (such as new customer requests, discovery of dependency issues, and feedback and learning from sprint deliveries) that will necessitate adjustments in the priority and definition of the stories in a release.
The goal is to do just enough release planning to support a reasonable estimation of which stories can be delivered in the release and more detailed planning for the next few sprints. Therefore, it’s recommended to do just enough release planning to scope out the release and support sprinting planning for the first few sprints, and then continue refining the release plan on a regular basis.
A release can be defined many ways, including:
Release planning assumes that a sufficient product backlog of user stories already exist, at least at the epic level. It also assumes that the stories in the product backlog are prioritized.
If the release definition is date-based, then we need to select no more user stories than the development team is likely to be able to complete by the given end date. If the release is functionality-based, then we still need to estimate when the stories are likely to be completed. If the projected end date is too far away, we should define one or more intermediate internal releases goals before the external release as milestones to monitor scope and time risks. The approach we take to either issue is to:
For a functionality-based release, if the estimated completion date computed above is acceptable, then all the stories can be selected for the release. If not, then revert to a date-based release.
Grooming the Release Plan
Over the course of time, we can expect the teams’ velocities to change, new stories to be submitted or discovered, and the relative priority on the remaining stories to change. Since we expect these kinds of changes, the team should avoid planning too far ahead in too much detail. Eventually the team will have completed most of the stories that were broken down earlier, so a few epics need to be periodically split into small enough stories for sprinting.
In order to cope with change and planning in detail only a few sprints ahead, the team needs to periodically revisit the release plan. The team has to decide whether any new stories should be added to the release and whether the remaining stories in the release should be tackled in a different order. Given possible changes in the release contents or the team’s velocity, we need to assess the likelihood that all the stories in the release will be completed by the release end date. If the likelihood is low, we may have to remove some stories from the release.
The more often we groom the release plan, the more realistic the plan will be (and the less work it will take to reconcile it with reality in the future).
The goal is to do just enough release planning to support a reasonable estimation of which stories can be delivered in the release and more detailed planning for the next few sprints. Therefore, it’s recommended to do just enough release planning to scope out the release and support sprinting planning for the first few sprints, and then continue refining the release plan on a regular basis.
A release can be defined many ways, including:
- Date-based – The release is defined as the highest priority user stories that can be implemented by the given date.
- Theme-based – The release is defined as a coherent set of related user stories.
- Customer-based – The release is defined as a set user stories (and posibly bug fixes) requested by one or more key customers.
Release planning assumes that a sufficient product backlog of user stories already exist, at least at the epic level. It also assumes that the stories in the product backlog are prioritized.
If the release definition is date-based, then we need to select no more user stories than the development team is likely to be able to complete by the given end date. If the release is functionality-based, then we still need to estimate when the stories are likely to be completed. If the projected end date is too far away, we should define one or more intermediate internal releases goals before the external release as milestones to monitor scope and time risks. The approach we take to either issue is to:
- Estimate the stories – Make rough estimates of the relative size of the stories
- Establish velocity – Determine how many story points the team is likely to complete each sprint
- Compute forecast:
- A date-based release can be estimated to complete (velocity * number of sprints) story points.
- A functionality-based release can be estimated to complete in (total story points / velocity) sprints.
For a functionality-based release, if the estimated completion date computed above is acceptable, then all the stories can be selected for the release. If not, then revert to a date-based release.
Grooming the Release Plan
Over the course of time, we can expect the teams’ velocities to change, new stories to be submitted or discovered, and the relative priority on the remaining stories to change. Since we expect these kinds of changes, the team should avoid planning too far ahead in too much detail. Eventually the team will have completed most of the stories that were broken down earlier, so a few epics need to be periodically split into small enough stories for sprinting.
In order to cope with change and planning in detail only a few sprints ahead, the team needs to periodically revisit the release plan. The team has to decide whether any new stories should be added to the release and whether the remaining stories in the release should be tackled in a different order. Given possible changes in the release contents or the team’s velocity, we need to assess the likelihood that all the stories in the release will be completed by the release end date. If the likelihood is low, we may have to remove some stories from the release.
The more often we groom the release plan, the more realistic the plan will be (and the less work it will take to reconcile it with reality in the future).
