Building And Forecasting
an Agile Release Plan
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
V. Lee Henson CST / PMP

Certified Scrum Trainer

Project Management Professional

PMI- Agile Certified Practitioner

Certified Lean Agile Professional


Motivational Speaker & Executive
Coach
Author of The Definitive Agile
Checklist

Inventor of Rapid Release Planning

Information Technology / Psychology
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
2
A QUICK AGILE OVERVIEW
According to the Numbers...
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
3
✤
✤
✤
✤
Founded in 2007 - Salt Lake City, UT
AgileDad Specializes in Public & Private Certification
Workshops, Advanced Agile Training Courses, and
Organizational Coaching
Deep understanding of Agile & Traditional Project
Management, (PMP), RUP, Lean, Kanban, Scrum, (CST),
XP, & PMI-ACP
Proven Applied Agile Principles in Software, Hardware,
Financial, Insurance, Construction, Medical, Marketing,
Legal, Entertainment, Research, Military, Government,
Retail, Education, Law Enforcement, and many more...
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
4
What Problems Does Agile Try to
Solve?
Standish Group Results
(Chaos Report 1995 - 2009)
‣31.1%
of IT projects will be cancelled before
completion
‣52.7%
of completed projects cost on average 189%
over their original time and budget estimates
‣16.9%
of projects are completed on time and on
budget
‣The
larger the project, the more likely the
failureDeveloping software is tough and prone to failure
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
5
Why Do Projects Fail?
(even when we spend so much time planning them?)
Project Impaired Factors
% of Responses
1. Incomplete Requirements
13.1%
2. Lack of User Involvement
12.4%
3. Lack of Resources
10.6%
4. Unrealistic Expectations
9.9%
5. Lack of Executive Support
9.3%
Copyright The Standish Group International, Inc.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
6
But Agile is more than just
running
from past challenges...
67% of organizations find that Agile has improved the
frequency of their product releases.
May 2009 - Forrester Research
74% of organizations report that Agile practices
have resulted in increased productivity.
2008 State of Agile - VersionOne
66% of organizations have found reductions in cost
greater or equal to 10%
2008 State of Agile - VersionOne
57% of organizations report improvements in
execution capabilities due to increased company
wide collaboration.
May 2009 - Forrester Research
83% of organizations attribute improved
transparency and project level visibility to their
Agile practices
2008 State of Agile - VersionOne
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
7
Release planning Truth...
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
8
What Makes Release Planning So
Difficult?
1. Poor Story Preparation
‣
‣
‣
Story preparation is
CRITICAL to the success
of forecasting a Release
Plan
Most stories have poor
acceptance criteria
We need to establish and
learn how to ask people for
what we want instead of
always trying to explain
how to do it.
2. Improper
Conversations
‣
‣
‣
Having the wrong people in
initial conversations can
prove costly and cause
confusion
Failure to involve all teams
participating in the release
in the planning process
makes it impossible to
forecast
Teams want to know what
is coming next so that they
can be better prepared
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
9
How Accurate is Release Planning?
Type of Release Planning
% of Accuracy Amount of Time
1. Traditional Release Planning
17.1%
Weeks
2. Agile Story Review Planning
22.4%
Multiple Days
3. Agile Planning Poker
34.6%
1-3 Days
4. Rapid Release Planning
86.9%
< 90 Minutes
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
10
Agile Project Planning
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
Project Planning
•
“Plans are useless...planning is
indispensable”
- Eisenhower
•
Agile practices embrace continuous
planning
•
Always accurate, varying levels of
precision
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
12
The Five Levels of
Agile Planning
Agile teams plan their projects at 5 levels:
Product Vision
T-365
Product Roadmap
T-365 to T-90
Release Planning
T-60 to T-45
Iteration Planning
T-0
Daily Planning
T+1 to T+14
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
13
Vision & Strategy
•
It is EXPECTED that a Great Vision
& Strategy to achieve the vision are
in place early in the Agile
engagement.
•
Without BOTH a Vision & Strategy,
teams will be lost when it comes to
understanding the why behind the
what.
•
The team is responsible for doing
everything possible to execute on the
vision by completing the work from a
rank ordered product backlog.
•
The Strategy is the most overlooked
portion of the project preparation.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
14
The Elevator Statement
•
FOR (target customer)
•
WHO (is suffering from this
problem)
•
THE (product formal name) is a
(product type or category)
•
THAT (provides this key benefit or
compelling reason to buy).
•
UNLIKE (the primary competitive
alternative)
•
OUR PRODUCT ( final statement
of primary differentiation)
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
15
The Product Roadmap
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
16
Agile 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
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
17
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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
18
The 3 C’s of a 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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
19
INVEST Attributes of Good Backlog Items
Independent
Avoid dependencies with other stories
Write stories to establish foundation
Combine stories if possible to deliver in a single iteration
Estimable
Enough detail should be listed to allow the team to estimate
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
Negotiable
Stories are not a contract
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
Sized Appropriately
Each story should be small enough to be completed in a single
iteration
Small detailed stories for the near future
Larger stories are okay if planned further out (Epics)
Valuable
Each story should show value to the Users, Customers, and
Stakeholders
Testable
Acceptance criteria stated in customer terms
Automate whenever possible
All team members should demand clear acceptance criteria
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
20
The Index Card
Business Priority
MoSCoW
Title - The title should be 10 words or less.
H-M-L
M-S-C-W
Description- As a ________
I would like to ______________________________
so that ______________________________.
XS - S- M
- L - XL
PO T-Shirt Size
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
21
The Index Card (The Back)
Acceptance Criteria:
Thou Shalt Allow This to happen.
Thou Shalt NEVER Allow This to happen.
Etc.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
22
The Index Card - Analysts
FA
H-M-L
BA
Title - The title should be 10 words or less.
M-S-C-W
Description- As a ________
I would like to ______________________________
so that ______________________________.
XS - S- M
- L - XL
TA
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
23
Rapid Release Planning
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
24
Defining Velocity:
•
How much work can we
fit in the release?
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
25
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?
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
26
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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
27
Release vs. Sprint Planning
Release Planning
Iteration Planning
Attendees
Teams, 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 Iteration plan (= detailed
plan for multiple
plan of tasks for one
iterations)
iteration)
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
28
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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
29
The Agile Release:
The water line determines
our Release Backlog
Given our product backlog and release date,
How many cups (iterations) can we fill?
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
30
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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
31
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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
32
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
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
33
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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
34
Release Plan Reporting:
•
People expect to know about
changes to requirements in the
product backlog.
•
Contract phases and dates.
•
Team Velocity
•
Cost
•
The ability to re-project the
number of iterations needed to
complete the work slated in the
release.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
35
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 preset amount of time 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
preset amount of time 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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
36
Rapid Release Planning Instructions:
•
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 few 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.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
37
Rapid Release Planning Instructions:
•
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 places items into
future sprints to identify any items that could be considered at risk of not making the
release.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
38
The Sliding Scale
•
•
•
The amount of time allowed for each step in the Rapid Release
Planning Process varies based on the number of items you are
trying to plan for, the number of people, and whether teams are
remote or collocated. The scale at right should be used as a
guide and can be adjusted according to what works best for you.
Please remember:
1) The times are intentionally FAST! This is to perfect reaching a
true grit gut decision instead of pondering.
2) Every team member may not get to see every card. This is
PERFECTLY fine. They need to trust in the ability of the team
member that did see the card.
•
3) Movement of cards throughout the exercise is both normal and
expected.
•
4) Limit the number of people participating to no more than 50
People.
•
•
5) Video Record your teams executing this and send it directly to
me or upload via YouTube for a chance to win cool prizes!
Note: Remote teams should add 50% to the times listed.
# Of Items
# Of People
0-99 (5)
1 Team (+0)
100-199 (10)
2 Teams (+5)
200-299 (15)
3 Teams (+10)
300-399 (20)
4 Teams (+15)
400-499 (25)
5 Teams (+20)
500 (30)
6 Teams (+25)
Times in Parentheses should be added
together to calculate the TOTAL team time
needed for the RRP
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
39
Focusing On the Right Product
•
The Standish Group determined that 45% of all user
‘requirements’ are never used by the customer in the
delivered product**… (Why are you building it?)
• The result to the left
describes typical
implementations
• How can we make scope
changes ‘lean’?
** J. Johnson, Keynote Speech, XP 2002
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
40
Questions?
•
You now hold the keys to success!
•
You have been educated and empowered.
•
Visit often and drink from the well!
http://www.agiledad.com/
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
41
Background Materials:
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
42
Agile Resources:
•
Suggested URLs:
•
Home of Scrum = www.scrumalliance.com
•
Jeff Sutherland = www.jeffsutherland.com
•
Mike Cohn = www.mountaingoatsoftware.com
•
AgileDad = www.AgileDad.Com
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
43
Thank You!
Lee@AgileDad.com - Twitter @AgileDad LinkedIn leehenson@gmail.com
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
44
Disclaimer:
The preceding presentation was intended as a Lunch Conference Presentation for the PMI Northern Utah Chapter,
March Session in Sandy, Utah. No portion of this presentation should be copied, transferred, or reproduced without the
expressed written consent of AgileDad. Any company and or organization depicted in this material is purely fictitious and
is not intended in any way to represent and or mimic an existing company and or corporation. This presentation and any
broadcast thereof is intended for the sole use of the PMI Norther Utah Chapter. No other warranty or disclaimer stands or
supersedes this one.
Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.
45