Iteration Planning Guide

What Is It?
The purpose of the iteration planning meeting is
for the team to commit to the completion of a set
of the highest ranked product backlog items. This
commitment defines the iteration backlog and is
based on the teams velocity or capacity and the
length of the iteration timebox.

If we can split a product backlog item so that

its children deliver value, then our iterations
incrementally deliver value. If we split by process,
then we impact time to market because value is not
delivered until all the children are complete.
Compound stories can be easily split through
disaggregation.

Who Does It?

Complex Stories

Iteration planning is a collaborative effort involving

these roles:
ScrumMaster - facilitates the meeting
Product Owner - represents the detail of the
product backlog items and their acceptance criteria
Delivery Team/Agile Team - define the tasks and
effort necessary to fulfill the commitment

Before We Begin
Before getting started we need to ensure:
The items in the product backlog have been sized
by the team and assigned a relative story point
value
The product backlog is stack ranked to reflect the
priorities of the Product Owner
There is a general understanding of the acceptance
criteria for these ranked backlog items

Equal Opportunity Backlog

The product backlog addresses fixes to existing
functionality and new functionality. The order in which
a product backlog item is scheduled is completely
independent of its ancestry.
We can further generalize and say that, for the
purpose of iteration planning, the important attributes
for a product backlog item are:
It is small enough to be completed in
the iteration
We can verify it has been implemented correctly

Right Sizing Backlog Items

Product backlog items too large to be completed in
an iteration need to be split into smaller pieces. The
best way to split product backlog items is by value
not by process.
www.rallydev.com

Complex stories present a different challenge.

Bill Wake enumerates twenty techniques at:
http://xp123.com/xplor/xp0512/index.shtml

Plan Based on Capacity

Mature teams may use velocity to determine what
product backlog items to commit to during the
iteration.
New teams may not know their velocity or it may
not be stable enough to use as a basis for iteration
planning. An approach for new teams is to make
commitments based on the teams capacity.

Determining Capacity
The capacity for the team is derived from three
simple measures for each team member:
Number of ideal hours in the work day
Days in the iteration that the person will be available
Percentage of time the person will dedicate to this
team

The Planning Steps

1. The Product Owner describes the highest ranked

product backlog item
2. The team determines the tasks necessary to
complete that product backlog item
3. Team members volunteer to own the tasks
4. Task owners estimate the ideal hours they need to
finish their task
5. Planning continues while the team can commit to
delivery without exceeding capacity
If any individual exceeds their capacity during
iteration planning then the team collaborates to better
distribute the load.

2013 Rally Software Development

Iteration Planning Agenda

ScrumMaster

Product
Owner

Agile
Team

Opening - Welcome; review purpose, agenda, and organizing tools

Product Vision and Roadmap - Remind the team of the larger
picture
Development status, state of our architecture, results of
previous iterations - Discuss new information that may impact plan
Iteration name and theme - Collaborative decision
Velocity in previous iteration(s) - Present the velocity to be used
for this release
Iteration timebox - Determine the timebox and total working days.
Subtract holidays or whole-team impacting events.
Team capacity (availability) - Each team member calculates their
capacity based on personal availability, allocation to this and other
projects, productive time for tasks in this iteration each day
Issues and concerns - Check in on any currently known issues and
concerns and record as appropriate
Review and update definition of Done - Make updates based on
technology, skill, or team makeup changes since the last iteration
Stories/items from the product backlog to consider - Present
proposed product backlog items to be considered for the iteration
backlog
Tasking out - Delivery Team determines tasks, signs up for work,
estimates tasks they own; Product Owner answers clarifying
questions, elaborates acceptance criteria as appropriate;
ScrumMaster facilitates collaboration
New issues and concerns - Check in on any new issues and
concerns based on tasking out and record as appropriate
Dependencies & Assumptions - Check in on any dependencies or
assumptions determined during planning and record as appropriate
Commit! - ScrumMaster calls for a fist of five on the plan; Agile
Team and Product Owner signal if this is the best plan they can
make given what they know right now and commit to moving to the
next level of planning (daily)
Communication/Logistics plan - Review & update for this iteration
Parking lot - All parked items should either be determined resolved
or turned into Action Items
Action items/plan - Distribute action items to owners
Retrospect the Meeting - To make the meetings useful for
everyone, we solicit feedback on the meeting itself
Close & CELEBRATE a successful planning meeting!
www.rallydev.com

2013 Rally Software Development

Release Planning Guide

What Is It?

The purpose of release planning is to commit to a

plan for delivering an increment of product value.

Who Does It?

Release planning is a collaborative effort involving
these roles:

ScrumMaster - facilitates the meeting

Product Owner - represents a general view of the
product backlog
Delivery Team/Agile Team - provide insights into
technical feasibility and dependencies
Stakeholders - act as trusted advisors as decisions
are made around the release plan

Action plans/SMART goals from prior release and

retrospective
Items and defects to consider
Development/architecture information
Velocity from previous iterations or estimated
Organizational and personal calendars
Input from other teams/subject matter experts to
manage dependencies

Output

Release plan and commitment

Issues/concerns/dependencies/assumptions to be
monitored
Any new items for the release backlog
Suggestions to improve future planning meetings

Release Planning Checklist

2
3
4

Product Backlog
(potential work)

Iteration Backlog
(work in progress)

Before We Begin
Before getting started, release planning needs:

A ranked product backlog managed by the Product

Owner
Input from the team about overall capabilities, known
velocity and technical impacts
High-level vision and market/business objectives
An acknowledgment of whether new product backlog
items may be needed

Materials Needed

Posted purpose and agenda

Organizing tools: working agreements, parking lot,
communication/logistics plan, issues and concerns,
dependencies and assumptions, decisions
High touch: Flip chart or whiteboard and markers
High tech: Projector, computer that can access
needed data and tools, and a way for the computer to
be shared
Planning Data (see below)
Results of previous iterations and releases
Feedback from stakeholders on the product, market
situation and deadlines

www.rallydev.com

Make sure the person responsible for

making priority decisions about big features is
available, be it Analyst, Product Manager or Exec.

2. Do you have a ranked backlog?

5-15 high-level features the Product Owner hopes

to have in this release. Write each on an index card.

3. How will you size your items?

Establish a common baseline for sizing. Consider

bringing a broad group of individuals together and
have them size some backlog items.

4. Whos coming?

Everyone who is impacted by the release needs to

be in this meeting to help develop the plan, identify
dependencies, and commit to the release.

5. Plan for logistics

Write an agenda in advance. Consider room size.

Review the agenda beforehand with ScrumMasters
or team leads. Provision for breakout rooms,
flipcharts and stickies, food and drink.

6. What about multiple or distributed teams?

Consider plane tickets if its only 4 times per year.
Or assign a scribe per distributed team to enter
planning information.

7. Do I need help?

Planning Data

1. Wheres your Product Owner?

2013 Rally Software Development

This is an expensive meeting, and potentially a

large one. Consider bringing in an experienced
facilitator to help.

In
Charge

Release Planning Agenda

Opening - Welcome; review purpose and agenda, organizing tools, business sponsors introduction. It is
helpful for the business sponsor to share a few words on the importance of this release and the teams
upcoming work.
Product Vision and Roadmap - Remind the team of the larger picture.
Development status, state of our architecture, results of previous iterations - Discuss any new
information that may impact the plan.
Release name and theme - Inspect current status as it relates to your roadmap themes and
collaboratively decide on adjustments to name and theme to achieve a specific, current business goal
for the release.
Velocity in previous releases and iterations, or your estimated velocity - Present the velocity (if
available) to be used for this release.
Release schedule and number of iterations - Review key milestones and special events followed by
collaborative decision on timeboxes for the release and iterations within the release.
Issues and concerns - Check in on any known issues and concerns and record as appropriate.
Review and update definition of Done - Make any appropriate updates based on technology, skill, or
changes in team makeup since the last release.
Stories/items from the product backlog to consider - Present proposed product backlog items to be
considered for scheduling into this release.
Determine sizing values - Agree upon sizing values to be used in the release planning if velocity is
unknown.
Coarse sizing of stories intended for the release - Delivery team determines the size of items under
consideration for the release and splits items too large for iterations in the release. Product Owner and
subject matter experts answer clarifying questions and elaborate acceptance criteria and proper story
splits. ScrumMaster facilitates collaboration.
Map stories to iterations in the release - Delivery team and Product Owner move items to iterations
based on size and velocity; ScrumMaster facilitates.
New issues and concerns - Check in again on any new issues and concerns based on the previous
work and record as appropriate.
Dependencies & Assumptions - Check in on any dependencies or assumptions determined during
planning and record as appropriate.
Commit! - ScrumMaster calls for fist of five on the plan. Delivery team and Product Owner signal if this
is the best plan they can make given what they know right now and commit to moving to the next level
of planning (iteration).
Communication/Logistics plan - Review and update communication and logistics plan for this release.
Parking lot - All parked items should either be determined resolved or turned into Action Items.
Action items/plan - Distribute action items to owners.
Retrospect the Meeting - Because we want these meetings to be useful for everyone, we solicit
feedback on the meeting itself.
Close & CELEBRATE a successful planning session!

- ScrumMaster
www.rallydev.com

- Product Owner

2013 Rally Software Development

- Agile Team
2

User Stories Guide

What are they?

Why?

A user story is one or more sentences in the

everyday or business language of the user
or customer that captures what the user or
customer wants to achieve through software.
They tell a short story about how the user,
customer or other persona will use the
system, and what benefit they derive from
the functionality.

The why in a user story specifies the value

to the who. This is the primary purpose for
delivery. The inclusion of why gives user
stories their richness. The why is important
context that helps the team design solutions
that meet the real needs of users and
customers. The why is also critical in Agile,
which is a value-driven approach to software
development. The why keeps the value front
and center, helping the Product Owner with
ranking. If you cannot find the why for a
story, you might have a story with no value.

The goal is to provide context, which helps

the Product Owner effectively manage
and rank the backlog, and help the team
understand how to implement functionality
with the goals of customers in mind.

Template

Who?

The user story template is designed to help

Product Owners and others tell stories with
The who in a user story is the who who
wants the functionality and who benefits from a clear who, what, and why. The template
it. Typically, we use a role or persona, so that is simply a guide. The key is to include the
elements.
everyone has a rich understanding of the
As a registered user, I want to reset my
needs and motivations of the who. Avoid
password, so that I can get back in to the
roles that are too general (e.g., As a user);
site if I forget my password.
instead, use roles that help the team imagine
As an unregistered user, I can sign up
for whom they are building software. Some
for the site, so that Im able to have a
stories have a system as the who. Even
personalized experience.
very technical stories should describe what
customer or user benefits.
As Tom, I want to only see updates from
close friends, so that I can view relevant
What?
updates during my time online.
The what in a user story specifies the need,
feature, or functionality that is desired by the Another Template
who. This is what the team will build into the Some stories benefit more than one who. In
software or service. The what should be clear that case, it can help to include multiple whoso the team knows what to design and build. why pairs.
www.rallydev.com

2013 Rally Software Development

what: Track history of what products

registered shoppers have viewed.
who: Registered Shoppers
why: So I can go back and find again (and
buy) what Ive researched previously
who: Marketing
why: So we can serve ads that are relevant
to the interests of individual registered
shoppers.

Getting Started
A simple statement in a user story format
gets us started, but doesnt tell the whole
story. The team needs more. The Three Cs
indicate the three elements of a user story
Card, Conversation and Confirmation.

Card
The card is an overview of who, what, and
why of a user story. The index card metaphor
(and sometimes literal format) represents a
small space for telling a succinct story, and
the fact that stories should be easy to move
around as we rank the backlog. The card
captures the general idea and is a promise
for a conversation.
As a registered user, I want to
reset my password so that I can
get back into the site if I forget my
password.

For our password reset example, questions

might include:
What type of authentication do we need?
What information do we need to collect
about the user?
Are there different types of users that we
have to worry about?
The whole team can participate in these
discussions. Different roles and different
viewpoints will surface different questions
and concerns.

The Confirmation
The results of the conversation should be
captured as Acceptance Criteria. A welldefined user story is testable. How will the
Product Owner confirm that the story was
implemented properly?
Acceptance criteria are the conditions of
satisfaction and acceptance for the story.
Product Owners and the Delivery Team work
together to provide acceptance criteria and
remove any ambiguity from the user story.
High-level statements are usually fine and
they should be turned into acceptance tests
as implementation of the story begins.
Acceptance Criteria for our Reset Password
story might include:
Username, password, and email address
are all required. Display name can be
provided, but is optional.

Conversation
The card provides the basis for a
conversation between the Product Owner
or customer and the Delivery Team.
Through conversation, the Product Owner
and Delivery Team develop a shared
www.rallydev.com

understanding of the goals for functionality

as well as the constraints. Often the team
asks questions.

Passwords can be 6 200 characters in

length.
Passwords should be stored encrypted
and cannot be decrypted.

2013 Rally Software Development