(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.
|