How do I plan a release in Scrum?
The Scrum framework does not prescribe how to plan a release but many scrum teams will have a ‘release plan’ that they use to track progress towards a release of software.
A release plan is a complementary practice to Scrum that looks forward over several sprints and provides a forecast of when a coherent set of functions will be made available. By ‘complementary practice’ we mean a technique that is not a required element of Scrum but works, and is often used, alongside Scrum.
In order to create a release plan, it is necessary to have three things: a list of items that are required or are candidates for inclusion in the release; an estimate for the capacity of the team each sprint; a high-level estimate for each of the items on the list. The item estimates and the team capacity must be in the same units; for example, story points.
Release plans usually work in one of two ways. Either set a release date and forecast which of the items on the product backlog will done in time for the release, or associate a subset of the product backlog to the release and forecast when all of these items will be done.
Release plans are adaptable. They are designed for and expect change to occur. They provide stakeholders with a transparent look at how the team is progressing with the release.
What’s the difference between a release and a sprint?
A sprint is a one month or less time-box where a working and potentially shippable product increment is created. A release is a piece or set of working software that is made available to users in a live or production environment.
‘Potentially shippable’ means that it has met quality standards and could be released. It is not a requirement of Scrum that every product increment produced by a sprint is released.
Who tracks progress for a release?
The product owner is accountable for optimising the value of the product resulting from work of the development team. One way in which the product owner can accomplish this is by maintaining a forecast and release plan that describes the functionality that will make up a release and when it is expected to be made available to users in a live or production environment.
Where is the plan?
In Scrum a transparent product backlog contains the information used to create a release plan. The Scrum Guide states:
The product backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
The product backlog and the release plan will continue to evolve as they are adapted throughout the product lifecycle but specifically as an output of the sprint review.
Product backlog refinement is the act of adding detail, estimates and order to items in the product backlog. The estimates are provided by the development team.
When should the release plan be reviewed?
The release plan and forecast should be inspected during the sprint review and made transparent to stakeholders. Backlog items can be added, changed or removed from the product backlog at the sprint review so the release plan may need to be adapted at or after every sprint review.
What complimentary practices help?
The Scrum Guide doesn’t say how to estimate product backlog items. A common technique for estimating product backlog items is to use story points. Story points are "assigned" to product backlog items based on the anticipated relative effort required completed the story. In Scrum, the development team is accountable for giving these estimates.
Release burn up charts show progress towards completion of a given set of estimated product backlog items (that form the release). They map the completion of work on a sprint by sprint basis using empirical data in the product backlog.
