Rapid Release Planning

Rapid Release Planning
Session & Workshop

V. Lee Henson CST
V. Lee Henson CST
Certified Scrum Trainer
ADDIE Training Professional
Agile Coach & Trainer
Author of Agile Mentor Newsletter

(Published Monthly)
Author of The Definitive Agile Checklist
Inventor of Rapid Release Planning
Former Chairperson of the Scrum

Alliance Certification Advisory Board
Information Technology / Psychology
Background
Copyright 2011 Davisbase LLC.
The Setup:
When & Who Are We?:
It is CRITICAL to recognize what has happened so far in the process

and where we are now while we are performing these actions:
1) The corporate and product / project vision has been
established. Teams have been exposed to this leadership position.
2) With the help of executive leadership we have laid out a
roadmap outlining what items we anticipate will be delivered in
the next few quarters. Teams are exposed to the roadmap to
provide technical input.
3) The product Ownership Group, (PO, BA, FA, TA, Etc.), get
together to brainstorm and create cards for candidates to be
selected from for the upcoming release.
Product Owner:
Responsible for: Creation and

maintenance of a stack ranked
product backlog.
Gathering of customer, business, and
technical requirements and filtering
them down to a single product
backlog.
Full understanding of the product
and the process.
Maintaining upward visibility.
Representation of customer and or
sponsor to the end team
Agile Analysts:
There are 3 types of analysts to assist the product owner in creation and
maintenance of the product backlog:
1) Technical Analyst - This analyst understands the way that the current
product is built and can assist in determining technological feasibility of
future enhancements.
2) Functional Analyst - This analyst knows exactly how the current
product works and understands the direction in which the business
hopes to take the future of the product. This analyst is also typically very
savvy about how end users typically use the product.
3) Business Analyst - This analyst has a deep understanding of the
customers wants, needs, and desires. They often negotiate with the
business to get features into the product that the customer will actually
use.
The Product Ownership Cloud:
A single product owner would

have a very difficult time
meeting the needs of a large
organization.
Many organizations introduce
the concept of a product
ownership cloud.
Chief Product Owners lead
the charge by capturing
corporate direction and
working towards
implementation through
multiple product owners.
Each product owner works

with a team of analysts and
market specialists to best
define the requirements.
Architects or Principle
Developers are often
engaged early to determine
technological feasibility and
framework are in place.
The team becomes involved
at the release planning
phase.
The Product Ownership Cloud

CPO
PO
TA
T1
FA
BA
T2
TA
PO
FA
PO
BA
SM
TA
T3
FA
BA
TJ
8
Writing Great User Stories:
INVEST - Attributes of a Good Story
Independent
Estimable
Avoid dependencies with other stories
Enough detail should be listed to allow the team to estimate
Write stories to establish foundation
The team will encounter problems estimating if the story is too

big, if insufficient information is provided, or if there is a lack of
domain knowledge
Combine stories if possible to deliver in a single iteration

Negotiable
Sized Appropriately
Stories are not a contract
Each story should be small enough to be completed in a single

iteration
Too much detail up front gives the impression that more

discussion on the story is not necessary
Not every story must be negotiable, constraints may exist that
prevent it
Valuable
Small detailed stories for the near future

Larger stories are okay if planned further out (Epics)
Testable
Each story should show value to the Users, Customers, and

Stakeholders
Acceptance criteria stated in customer terms

Automate whenever possible
All team members should demand clear acceptance criteria
10
The 3 Cs of a Good User Story:
1) The Card - The topic of the backlog item, the high level
description of the desired system behavior.
2) The Conversation - Detailed requirements are only
discovered after the backlog item has been pulled into a sprint.
This is a dialog between the product owner and the
development team.
3) The Confirmation - Criteria that insures the backlog item was
completed to the specifications of the product owner. The
customer will evaluate the competed backlog item against the
acceptance criteria, and if all tests pass, approve the backlog
item by the end of the sprint.
11
The Card - Part 1

Title - The title should be 10 words or less.
Description- As a ________
I would like to ______________________________
so that ______________________________.
12
Writing a Good User Story

Description Template:
As a _________________________ I would like to __________________

so that ________________________________.
Example: As a newly Certified ScrumMaster, I would like to log in
to the Scrum Alliance so that I can rate my instructor.
13
Understanding Roles:
Different types of end users

may interact with the system
differently.
Each role may have many
different personas that will
exhibit different behaviors
and use the same system in
a very different way.
Roles help us define broad
stroke acceptance criteria
that should be applied
globally within a system.
14
Understanding Personas
Defining who more specifically

will benefit from what you are
building helps drive added value.
This helps teams focus on the 20%
of the features that are used
most of the time.
Using personas also helps the
team consume backlog items
with much lighter documentation
Most organizations create a
handful of most commonly used
personas to assist the team in
building the product.
15
What About Business Priority?
Two websites to assist with priority:

http://dotmocracy.org
http://www.innovationgames.com
We all know the business has a 3

point ranking scale for priority of
backlog items: High, Really High,
or Really Really High.
The business needs to use tools
to help them understand that
not everything can be of the
highest priority.
With the understanding that we
would not be doing the work if it
were not important, which items
have the greatest urgency?
Can we arrange them into High,
Medium, and Low categories?
16
The Index Card - Part 2

Business Priority
H-M-L

I would like to ______________________________
so that ______________________________.
17
Time vs. Relative Complexity
Lets paint the room!
How many hours will it take?
Why all of the different answers?
Have any of you painted

before?
Compared to something else
you have painted, would it be
easier to determine how difficult
it would be to paint the room?
Is it easier to reach consensus?
18
Planning Poker - Does It Work?
19
Lets Use a T-Shirt Size...
Smaller Than XS = a Task.
Extra Small = 1
Small = 2
Medium = 3
Large = 5
Extra Large = 8
Larger than XL = an Epic

20

Business Priority
H-M-L

I would like to ______________________________
so that ______________________________.
XS - S- M
- L - XL
PO T-Shirt Size
21
Understanding MoSCoW:
MoSCoW = more than a Russian Capital
Must Have
Should Have
Could Have
Would Like
Every iteration should have a mix of the

above types of items.
Stake holders LOVE the Would Likes.
The Product Owner drives the product
backlog and creates the rank order
based heavily on the MoSCoW ratings.
22

Business Priority
H-M-L
MoSCoW
M-S-C-W
I would like to ______________________________
so that ______________________________.
XS - S- M
- L - XL
PO T-Shirt Size
23
Create Five Stories
Think about what you have learned about user

stories Take a few moments to create five Story
Cards that look like the ones we have created so
far:
1) Make 5 cards each with a title & description.
(Bonus points for using roles & personas in the
description.)
2) Take the 5 cards and give them each a priority.
(Remember, this is from the business perspective.)
3) Take the 5 cards and give them each a MoSCoW
rating. (Remember, this is from the customer
perspective.)
4) Next, take the 5 cards and give them a T-Shirt size
based on relative complexity & scope.
5) Finally, take the 5 cards and place them in stack
rank order. Be certain to take all 3 corners into
consideration when placing them in order.
24
The Formula
Here is the formula for correct placement of stack rank

order of your backlog items. Address risk by performing
the items with the highest complexity earlier working
towards the lower complexity items later in the
process:
Must Have
High Priority
Would Like
H-M-L
1) All Must Have High Priority items should be

considered first and foremost.
Must Have
Medium
Priority
2) Be certain to get at least one Would Like in every

sprint. Next should be one Would Like High Priority item.
Must Have
Low Priority
3) Next should be the Must Have Mediums and Must

Have Lows.
Should Have
H-M-L
4) The Shoulds go next from High to Low Priority.
Could Have
H-M-L
5) Finally, place the Coulds from Highest to Lowest

Priority.
Note: Dependencies trump priority & moscow rating.
All states are stack ranked from highest to

lowest risk unless the velocity of the Sprint
does not afford this as an option. Team
velocity always prevails.
25

FA
H-M-L
BA
M-S-C-W
I would like to ______________________________
so that ______________________________.
XS - S- M
- L - XL
TA
26
Agile Release Planning:
27
Defining Velocity:
How much work can we fit in

the release?
28
Determining Velocity:
What has the team been able to do in the past?
Have they ever worked together?
Do we have historical estimates from a previous similar project?
How much total team time do we have?
How much team time do we predict the first story will take us?
29
What Is a Release?
In order to have a release, you need the following three

elements:
1) A start and end date.
2) A set of work for the team to complete.
3) A customer to pass off on final acceptance of the work.
30
Release vs. Sprint Planning

Release Planning
Iteration Planning
Attendees
Team, SMEs and

product owner
required. Managers/
customers optional.
Team, SMEs and

product owner
required. Managers/
customers optional.
Lowest level of work

breakdown
User stories
Tasks
Estimates Provided in
Points, t-shirt sizes, or

duration (weeks)
Hours
Output of meeting
Release plan (= high

level plan for multiple
iterations)
Iteration plan (=
detailed plan of tasks
for one iteration)
31
The Product Backlog in Release:
Imagine for a moment that

the water cooler pictured
contained all of the features
we could ever want in the
product. Each listed in stack
ranked order and ready to
be placed into a tentative
release.
32
The Agile Release:

The water line determines
our Release Backlog
Given our product backlog and release dat

How many cups (iterations) can we fill?
33
Release Planning Woes:
Teams with different length

iterations make release
planning a real challenge.
The size (length) of the
iterations should remain as
consistent as possible.
It is truly up to the team to
determine what their true
velocity really is.
34
Value of Agile Release Planning:
Allows for planning for a series of iterations at a high level,

reducing waste in planning detailed tasks for requirements we
are uncertain about.
Allows for communication of the entire scope of the release to
project teams and stakeholders around a high level plan.
Protects the ability to remain flexible and agile by embracing
changes in requirements.
Serves as a guide, a baseline, and is expected to be updated
based on collaboration and the emerging product.
35
Value of Release Planning Realized:
Understand the need for human and

other resources as the macro release
level; understand possible decision
points for make vs. buy, integration, etc.
Provides the customer and leadership
with an idea of how a large project is
progressing.
Involves the team in its creation, which
means more buy-in, accuracy, and
empowerment.
I know things in a project are going to
change, but in my agile projects, I know
this information much sooner which
allows for good decision making.
~ Joe CEO
36
What a Release Plan is Not:
A release plan is not entirely

predictive or prescriptive.
A release plan is not planned
at the task level.
A release plan is not frozen,
(aka Scope Control)
There is really still no crystal
ball to insure 100% accuracy.
37
Rapid Release Planning:
38
Rapid Release Planning Instructions:
1) Print out all of the story cards you hope to be included in the release leaving off
the product owner t-shirt size. (After all, we would not want to influence the team.)
2) Place all of the cards in a large box, bucket, or basket.
3) Invite all of the teams participating in the release to be part of the rapid release
planning session to gather around a large table.
4) Explain that in a moment you will be dumping out all of the cards. The team will
have a pre-allocated time, (based on a scale), to find a card they all agree is
small in scope.
5) Once the team has identified a small benchmark item, explain they will have a
set number of minutes to place all of the remaining cards in columns on the wall
listed as small, medium, and large relative to the first item and to each other.
6) If a team member picks up a card they are uncertain about, have them return
the card to the table for other team members to review.
39
7) If an item is smaller than small, make a column for extra small. If the item is
larger than large make a column for extra large.
8) If an item is placed in the wrong column on the wall, feel free to move it. Any
card can move except for the initial small benchmark item.
9) For the final minute / seconds, I command silence and have the team
carefully study as many items on the wall as they can in an effort to allow for
any final adjustments to be made.
10) Once the time expires, I excuse the team for an extended lunch and ask the
product owners to stick around for a while so we can do a quick comparison.
11) Any items with no disparity or with only one column of difference in either
direction between the product owner and the team is a good enough
estimate. The team will get better at estimating as they go and product owner
will have a lot fewer items for additional review. The teams estimate in this case
is the final one.
40
12) If there is more than one degree of separation in the t-shirt size between the
product owner and the team, this warrants additional discussion regarding that item.
In most cases this limits the number of items requiring additional conversation to a
much smaller number.
13) Outliers are marked with both the team size and the PO size and placed in a
separate column for additional discussion.
14) When the team returns, we talk about the outliers for a time-boxed period of five
minutes each in an attempt to clarify scope.
15) The teams estimate stands and we move quickly through the items.
16) Before we exit the room, the team takes a sheet of round stickies and identifies any
backlog items in the release that have an internal or external dependency.
17) Based on the teams projected velocity, the product owner tentatively places items
into future sprints to identify any items that could be considered at risk of not making
the release.
41
Thank You!
Lee.Henson@DavisBase.org - Twitter @AgileDad - LinkedIn leehenson@gmail.com
42

Rapid Release Planning

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapid Release Planning

Uploaded by

Copyright:

Available Formats

Rapid Release Planning

Session & Workshop

V. Lee Henson CST

Certified Scrum Trainer

ADDIE Training Professional

Agile Coach & Trainer

Author of Agile Mentor Newsletter

Author of The Definitive Agile Checklist

Inventor of Rapid Release Planning

Former Chairperson of the Scrum

Copyright 2011 Davisbase LLC.

When & Who Are We?:

It is CRITICAL to recognize what has happened so far in the process

Responsible for: Creation and

Copyright 2011 Davisbase LLC.

The Product Ownership Cloud:

A single product owner would

Each product owner works

Copyright 2011 Davisbase LLC.

The Product Ownership Cloud

Writing Great User Stories:

Copyright 2011 Davisbase LLC.

INVEST - Attributes of a Good Story

Avoid dependencies with other stories

Enough detail should be listed to allow the team to estimate

Write stories to establish foundation

The team will encounter problems estimating if the story is too

Combine stories if possible to deliver in a single iteration

Stories are not a contract

Each story should be small enough to be completed in a single

Too much detail up front gives the impression that more

Small detailed stories for the near future

Each story should show value to the Users, Customers, and

Acceptance criteria stated in customer terms

Copyright 2011 Davisbase LLC.

The 3 Cs of a Good User Story:

The Card - Part 1

Copyright 2011 Davisbase LLC.

Writing a Good User Story

As a _________________________ I would like to __________________

Copyright 2011 Davisbase LLC.

Different types of end users

Copyright 2011 Davisbase LLC.

Defining who more specifically

What About Business Priority?

Two websites to assist with priority:

We all know the business has a 3

Copyright 2011 Davisbase LLC.

The Index Card - Part 2

Title - The title should be 10 words or less.

Copyright 2011 Davisbase LLC.

Time vs. Relative Complexity

Lets paint the room!

How many hours will it take?

Why all of the different answers?

Have any of you painted

Planning Poker - Does It Work?

Copyright 2011 Davisbase LLC.

Lets Use a T-Shirt Size...

Smaller Than XS = a Task.

Larger than XL = an Epic

The Index Card - Part 3

Title - The title should be 10 words or less.

MoSCoW = more than a Russian Capital

As a _______ I would like to