How to Manage the Release Backlog

Introduction The Backlog is the term used for the list of requirements in Scrum and other Agile development methods.  Usually the requirements are stated in the form of an User Story or an Epic, which is a very brief explanation about what is needed.
There are three different Backlogs:

  • The Business Backlog – used to store all requirements to e.g. a specific product or system. The requirements at this level is typically expressed at a high level as Epics.
  • The Release Backlog – is a subset of the Business Backlog, selected for implementation in a Release. The requirements are at this level detailed into User Stories in order to reduce uncertainties about their interpretation
  • The Sprint Backlog – is a subset of the Release Backlog, selected for implementation in a Sprint.

Here we focus on the Release Backlog!
Who is involved? Working with the Release Backlog involves different people with these responsibilities:

Business Product Owner Development Team Users O&M Team
Select from the Business
Backlog		 C A/R C I I
Prepare for implementation C A/R C I I
Maintain content C  A/R  C I I
Manage Changes C  A/R  C C C
Legend: R=Responsible; A=Accountable; C=Consulted; I=Informed

What is the input? The input to the Release Backlog is the Product Backlog.
Which tasks are expected? The following tasks is expected:

Task Description
Select User Stories and Epics from the Product Backlog The Product Owner select User Stories and Epics from the Product Backlog. The selection is based on the assigned priorities in the Product Backlog, during selection Business might be consulted.
When selecting, User Stories or Epics that have a relationship, e.g. one is a precondition for the other, has to be selected for the same release. Sharing e.g. the same data shall not necessarily be considered a dependency.
The selection continue until the sum of effort estimates equals the available development effort for the release – it is wise to leave a margin typically 20% for contingency!
When the Release Backlog is full it is put under change control.
Prepare top User Stories and Epics for implementation. Before the development starts, the Product Owner and members from the Development Team walk-though the highest priority User Stories and Epics to verify that they are fit for implementation in a Sprint including a brief definition of ‘Done’.
Any uncertainty is resolved before the Release Starts by consulting the Requester or other Subject Matter Experts.
Maintain the Release Backlog During the Release the group consisting of the Product Owner and members from the Development Team on a regular basis walk-though the items on the top of the list in order to ensure they are fit for implementation in the upcoming Sprint(s), i.e. any big uncertainty in the User Story/Epic shall be resolved before the next Sprint starts.
In these walk-through the group can decide to work on splitting an Epic into smaller User Stories in order to minimise the risk when implementation start in the next Sprint.
Manage change to the Release Backlog During the Release changes to the Release Backlog should be kept to a minimum and only the Product Owner can accept/reject a proposed change.
Proposal to change is therefore addressed to the Product Owner who consult e.g the Development Team or Business or both to assess the risk the change represent to the success of the Release before deciding whether to accept or reject the decision.

How shall the result be Controlled During the release the Release Backlog is kept under strong change control by the Product Owner.
What is the output? The output is a well maintained Release Backlog which is the single source of requirements to the Release.
When can we exit? The process do stop when the Release is completed and the content of the Release Backlog is empty or the remaining User Stories/Epics is agreed to be transferred back to the Product Backlog or permanently removed because they have become obsolete.
Hints and Examples The …
…