Task: Plan release
Plan a release.
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs

        (Supplements core Scrum)

        Synopsis

        The team plans the release by selecting stories to be included in the release (by adding them to the Release Backlog from the Product Backlog), taking into account the team's velocity.

        Value 

        The purpose of planning a release is for the team to commit to completing a collection of stories to be delivered as part of a release. The Release Plan serves as the foundation from which each Sprint will be planned.

        NOTE: Some teams may not plan specific releases, but instead just deliver the desired functionality in a series of sprints. In that case, they would not define a Release Backlog, but instead just select work items for each Sprint from the Product Backlog instead of the Release Backlog. 

        Pre-requisites

        The project area has been set up.  The Product Backlog has been refined by the team. The Product Backlog has a preliminary ranking and sizes have been provided for highly ranked work items.

        The Product Owner has developed an initial Product Vision and made it accessible to the team.

        Prepare

        The Scrum Master performs the following steps.

        1. Create a plan for the release

        Create an plan to be populated during the meeting (may be empty or have some preliminary information).

        2. Send out invitations

        Send out meeting invitations.

        Conduct

        1. Introduction

        The Scrum Master reviews the purpose of the meeting and ground rules.

        2. Review the Product Vision

        The Product Owner presents the current vision, with a focus on recent changes.

        3. Detail the release plan

        The team discusses the following:

        • What are the Release themes / minimum marketable features?
        • Review desired release start/end dates from the business.
        • Review impediments and risks.
        • Do we have any decisions we need to defer to the last moment responsible?
        • What are the milestones/deliverables expected?
        • Any other constraints/dependencies?
        • What is the capacity (velocity) of the team?
        • What is the sprint duration?

        4. Select stories for the release

        The Product Owner proposes which stories should be delivered in the release, and why.

        The team discusses each story proposed for the release, starting with the highest ranked.

        Specifically:

        a. Do we agree that this story is correctly ranked?
        If the work item is lowered in rank, then discussion of the story is deferred and the next highest ranked story is discussed.

        b. Do we agree with the size of this story?

        c. Is the story sufficiently understood?  Should this story be broken down further and some aspect of it be moved to a later release?
        Refactoring the stories, re-estimation and re-ranking may be required.

        d. Should this story be included in the release?

        Make updates as discussion proceeds.

        The following substeps provide additional guidance when selecting stories to be included in the release. They can be done multiple times in any order.

        4.1 Include stories in the release

        Start with the highest ranked "Must" stories, then move to "Should" stories in ranked order.

        Epics are not directly included in a release.  If an entire Epic is to be done in a given release, include all its' stories in the release.  You then have the flexibility to make changes later and allocate some stories to a later release.

        4.2 Review total story points planned for the release

        Are the total story points allocated to the release less than the release velocity?

        If so, and all "Must" stories have been added to the release, discuss whether to release sooner, or to continue adding "Should" stories.

        If the total story points is greater than the release velocity, then discuss whether to extend the release date, remove stories, or both.

        Change any "Must" stories that cannot fit in the release to "Should".

        4.3 Remove stories from the release

        If the total story points is greater than the release velocity, then you need to remove stories from the release.

        Move the lowest ranked stories to the Product Backlog until the Release Backlog is achievable by the release date.  

        5. Commitment

        The team discusses:
        What issues, concerns, or dependencies do we have?
        Can we commit to the release as a team, knowing what we do today?  

        6. Ongoing during the meeting

        New ideas are captured as stories/epics.
        The business value is discussed as ideas are captured  (or in notes and created later). Those with high business value may be ranked, refined and added to the Release Backlog, otherwise ideas are captured at a high level and left in the Product Backlog to be refined at a later time.

        Impediments and risks are logged.

        Follow-up

        The Scrum Master performs standard meeting follow-up items. This includes creating work items from meeting notes, soliciting feedback from absent members, and resolving any work item associated with the meeting.

        The Scrum Master also updates the timeline in plans/tools, and creates a snapshot of the release plan.  A snapshot captures the current state of a plan.  You can use the snapshot later to compare with the future states of the plan to identify trends. 

        More Information