Building And Forecasting an Agile Release...

Copyright 2013 AgileDad LLC Licensed for Classroom Use Only.

Building And Forecasting

an Agile Release Plan


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

2


According to the Numbers...

A QUICK AGILE OVERVIEW

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

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

5


Why Do Projects Fail? (even when we spend so much time planning them?)

Copyright The Standish Group International, Inc.

Project Impaired Factors % of Responses

13.1%

12.4%

3. Lack of Resources 10.6%

4. Unrealistic Expectations 9.9%

5. Lack of Executive Support 9.3%

1. Incomplete Requirements

2. Lack of User Involvement

6


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

But Agile is more than just running

from past challenges...

7


Release planning Truth...

8


What Makes Release Planning So Difficult?

1. Poor Story Preparation 2. Improper

Conversations

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

‣ 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

9


How Accurate is Release Planning?

Type of Release Planning % of Accuracy Amount of Time

17.1% Weeks

22.4% Multiple Days

3. Agile Planning Poker 34.6% 1-3 Days

4. Rapid Release Planning 86.9% < 90 Minutes

1. Traditional Release Planning

2. Agile Story Review Planning

10


Agile Project Planning


Project Planning

• “Plans are useless...planning is

indispensable”

- Eisenhower

• Agile practices embrace continuous

planning

• Always accurate, varying levels of

precision

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

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.

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)

15


The Product Roadmap

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

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.

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

20


The Index Card

Title - The title should be 10 words or less.

Description- As a ________ I would like to ______________________________

so that ______________________________.

Business Priority

H-M-L

PO T-Shirt Size

XS - S- M - L - XL

MoSCoW

M-S-C-W

21


The Index Card (The Back)

Acceptance Criteria:

Thou Shalt Allow This to happen. Thou Shalt NEVER Allow This to happen. Etc.

22


The Index Card - Analysts

Title - The title should be 10 words or less.

Description- As a ________ I would like to ______________________________

so that ______________________________.

FA

H-M-L

TA

XS - S- M - L - XL

BA

M-S-C-W

23


Rapid Release Planning

24


Defining Velocity:

• How much work can we

fit in the release?

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?

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.

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

plan for multiple

iterations)

Iteration plan (= detailed

plan of tasks for one

iteration)

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.

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?

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.

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.

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

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

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.

36



• 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. 37



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

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?)

** J. Johnson, Keynote Speech, XP 2002

• The result to the left

describes typical

implementations

• How can we make scope

changes ‘lean’?

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/ 41

http://blog.agiledad.com


Background Materials:

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

43

http://www.scrumalliance.com

http://www.jeffsutherland.com

http://www.mountaingoatsoftware.com

http://blog.agiledad.com


Thank You! [email protected] - Twitter @AgileDad -

LinkedIn [email protected] 44

mailto:[email protected]

mailto:[email protected]


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.

45

Building And Forecasting an Agile Release...

Documents

Transcript of Building And Forecasting an Agile Release...