1. Create a plan for the release

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

Create a new release in the timeline (if not already present).  Set start and end dates for the release. (If not known, make a best guess). See Creating timelines, iterations, and iteration types.

Create the release plan for the release. See Creating plans.

Add a "Release Plan" page (for textual details).  See Adding plan pages.

2. Send out invitations

Send out meeting invitations.

See Meetings and Rational Team Concert .

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.

Display the Vision tab of the Product Backlog.

a. In the web interface, click Plans > All Plans.  Then click Product Backlog.

b. Click the Product Vision tab

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? All Sprints should have the same duration.

Create a page on the release plan to capture release plan information.

• Click Plans > All Plans.  Then click the release plan.
• Add a page Release Plan. See Adding plan pages.
• Capture the results of the discussion on this page.

Display the team dashboard, Scrum Master tab.  The team discusses the impediments and risks displayed on the dashboard.

The velocity of prior release sprints can be viewed on prior release plans under Plan Details > Velocity.

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.

Display the Ranked List view of the Product Backlog. 

Hover over each work item to display key information without having to leave the ranked list.

To modify rank, click and drag the work item up or down (click at the far left of the work item), or type a new number in the "rank" column.  

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.

To include stories in the release:

• Check one (or more) stories using checkboxes at the left.
• Click Actions > Plan Items For > [Release name].  

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

To view the total story points planned for the release:

• Expand the Plan Details section.
• Click on Progress and look at the progress bar.

You can calculate a projected release date based on the team's capacity as follows:

The progress bar shows the remaining work in points assigned to the release.  Divide this by your expected team velocity to determine a minimum duration for the release.  Based on your Sprint duration, extend the date so that it aligns with the end of a Sprint.

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.

Display the Ranked List view of the Release Backlog (set View As to Ranked List). 

Hover over each work item to display key information.

To defer a work item to the Product Backlog:

• Check one (or more) stories using checkboxes at the left.
• Click Actions > Plan Items For > Product Backlog

If you adjust the release date, document this on the release plan tab, and update the project timeline. See Modifying timelines and iterations.

5. Commitment

• 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 (or in notes and created later).
The business value is discussed as ideas are captured.  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.

1. Standard meeting follow-up items

This includes creating work items from meeting notes, soliciting feedback from absent members, and resolving any work item(s) associated with the meeting.

2. Update the timeline 

Add Sprint iterations to the timeline by dividing the time until the next release by the agreed duration of sprints.

Creating timelines, iterations, and iteration types

3. Baseline 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. 

Taking a snapshot of a plan