Planning an Agile Project

for advance user

Sam Hwang
Sep 2009
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

2
Overview
• Agile Perspective on
Planning Projects vs.
“Traditional”
• Overview of Agile Planning
• High-Level Visioning
• One Pager
• Jefferies Exercise
• Product Backlog
• User Stories
• Spikes
• Write User Stories
• Release Planning
• Estimating
• Summary (Recognize that
change will happen, Utilize
Feedback, Ask for
Autonomous bits of
functionality)
3
Adaptive process control
• Useful when
¾ A market is moving so fast, that requirements
change frequently
¾ Technology is moving so fast, that
implementation details change frequently
• Embrace Change
• Inspect and Adapt

4
An Iterative Process
Design
Bui
ld
Test

v2.0 v2.1 Innovate v2.3 v2.4

5
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

6
The Scrum Process

Sprint Planning Meeting Sprint Review/

Sprint Retrospective 7
Planning
Vision
1

Release
Plan

2
Sprint
Plan
V1.0 V1.1 V1.2
3

8
Product Plan
Vision
1

One Pager
Elevator Statement(Short Description) Metrics:
Sign-ups xxx
For…who…that…Unlike…
Customer Benefits
Customer Attributes
1. More accurate …
1. People who work in … 2. Better customer service …
2. Those who need a … 3. …
3. … Performance Attributes
Feature / Ability to…
1. 3000 hits/hour
2. …
1. Share content with…
2. Personalized ads on… Tradeoff Matrix
3. …
Fix Firm Flexi
Major Milestones ed ble
Scope √
Xyz features xxx
Schedule
√
Abc features xxx
Resour
ces
√
Quality
√

9
Create your one pager
Elevator Statement Metrics: Metrics and ROI

For…who…that…Unlike… Sign-ups xxx

Customer Benefits
Customer Attributes
1. More accurate …
1. People who work in … 2. Better customer service …
2. Those who need a … 3. …
3. …
Performance Attributes
Feature / Ability to…
1. 3000 hits/hour
2. …
1. Share content with…
2. Personalized ads on…
Tradeoff Matrix
3. …
Fixed Firm Flexible
Major Milestones Scope √
Xyz features xxx
Schedule √
Abc features xxx Resources √
Quality √
10
Tradeoff matrix Dark Bar

Fixed Firm Flexible Target

Scope ✔ 300+ story points

Schedule ✔ 4-5 months

Resources ✔ $400,000

1 high bug per

Low Defects ✔
month

11
Product vision box
• Design a box for the software
¾ Even if the software won’t ship in a
box
• Write 3-4 key bullet points to sell
the software
¾ Easier to come up with 15
¾ The challenge is distilling the list to
3-4 key points
12
Sample product vision box
• Easy integration with most
insurance systems
• Support for multiple chairs
with appointment setting by
chair
• Multi-language support
• One click database backup

13
Write a press release (option)
• Collaboratively write the press release
you’d like to see released at the end
• What are the key points you’d make about
the product
• What quotes would you have and who
would they be from?
¾CEO? Team members? Customers?
14
Press release template
The _______company announced today the successful completion of the _________project.
This project provides _________________________________________________. The
customer for this project, ________________, indicated in a recent interview that they selected
___________ as their supplier due to the following key benefits:

1. ______________________________________
2. ______________________________________
3. ______________________________________

________________ also identified several features that they felt were particularly useful. These
include:

1. ______________________________________
2. ______________________________________
3. ______________________________________

____________ noted that the single most important benefit of their successful project was
“_________________________________________________________________.”
15
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

16
 d uc t Backlog
P r o

17
Product backlog

• A prioritized list of
requirements
• Items of highest value
at the top
• Prioritized by the
product owner
This
This is
is the
the
product
product backlog
backlog
18
 Items get more thought at the top
• Mirum est ut animus agitatione

• motuque corporis excitetut.

• Progressively refined
• Iam undique silvae
¾ As an item nears the top, it
• et solitudo ipsumque illud silentium
gets more thought
• quod venationi datur

• magna cogitationis • Items at the top are

• incitamenta

• sunt. Proinde cum venabere

¾ Smaller
• licebit, auctore me
¾ More thought through
• ut panarium et lagunculam

• sic etiam pugillares feras.

¾ Ready to be worked on
• Experieris non Dianam

• magis montibus quam

19
Reproduced with kind permission by
Mike Cohn mountaingoatsoftware.com
 Feature use – Keep it lean
Often or Always
Used: 20%
Rarely
Sometimes 19%
16%

Never
45%
Often
13%

Always
7% Rarely or Never
Used: 64%
Standish Group study reported at XP2002 by Jim Johnson, Chairman 20
A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
3
reservation.
As a hotel employee, I can run RevPAR reports
8
(revenue-per-available-room)
Improve exception handling 8
Bug #4334 – Improve error handling with… 1
Investigate PayPal integration 9
21
What’s in the Product Backlog
• Everything that needs to be done!
• Features
¾ Can be in the form of user stories
• Tasks/Bugs
• Spikes

22
What’s a Spike?
• A Spike is an investigation
• The deliverable is team knowledge
¾ Estimates
¾ Documentation
¾ Education
• A Spike is time boxed

23
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

24
User Stories make great backlog items
Card
•Stories are traditionally written on
note cards.May be annotated with
notes, estimates, etc.

Conversation
•Details behind the story come
out during conversations with
product owner
Confirmation
•Acceptance tests confirm the
story was coded correctly
Source: XP Magazine 8/30/01, 25
Ron Jeffries.
Samples from a travel website
As
As aa vacation
vacation planner,
planner, II
As user
As aa us want
er,, II wa nt to
to
want
want toto see
see photos
photos of
of the
the
rese
re rvee aa ho
serv tell ro
hote om..
room
hotels.
hotels.

As As
As aa frequent
frequent flyer,
flyer, II
As aa user,
user, II want
want to
to
cancel want
want toto rebook
rebook aa past
past trip,
trip.
trip.
trip,
cancel aa reservation.
reservation. so
so that
that II save
save time
time
booking
booking trips
trips II take
take often.
often.

26
Where are the details?
• As a user, I can cancel a reservation.
¾ Does the user get a full or partial refund?
• Is the refund to her credit card or is it site credit?
¾ How far ahead must the reservation be
cancelled?
• Is that the same for all hotels?
• For all site visitors? Can frequent travelers cancel
later?
¾ Is a confirmation provided to the user?
• How? 27
Details as conditions of satisfaction
• The product owner’s conditions of satisfaction can be
added to a story
¾ These are essentially tests

As
As aa user,
user, II can
can cancel
cancel aa
reservation.
reservation. Verify
Verify that
that aa premium
premium member
member cancan
cancel
cancel the
the same
same day
day without
without aa fee.
fee.
Verify
Verify that
that aa non-premium
non-premium member
member is is
charged
charged 10%
10% for
for aa same-day
same-day
cancellation.
cancellation.
Verify
Verify that
that an
an email
email confirmation
confirmation is is
sent.
sent.
Verify
Verify that
that the
the hotel
hotel is
is notified
notified of
of
any
any cancellation.
cancellation.
28
Details added in smaller stories
As
As aa premium
premium site
site
member,
member, II can
can cancel
cancel aa
reservation
reservation up
up to
to the
the
last
last minute.
minute.

As
As aa user,
user, II can
can As
As aa non-premium
non-premium
cancel
cancel aa reservation.
reservation. member,
member, II can
can cancel
cancel
up
up to
to 24
24 hours
hours in
in
advance.
advance.

As
As aa site
site visitor,
visitor, II am
am
emailed
emailed aa confirmation
confirmation
of
of any
any cancelled
cancelled
reservation.
reservation.
29
MMF: Minimal Marketable Feature

Headline

"As a (user),

Scenarios I want to (do something),

so that (I achieve some goal)" 30
Stocking the product backlog
• You can start by identifying only a sprint’s
worth of backlog items
• The key is to write product backlog items
with different levels of detail
¾ Fine-grained for stories about to be worked on
¾ Coarse-grained for stories further in the future

31
The product backlog iceberg
User Story
Theme
A description of desired
A collection of related
functionality told from the
user stories.
perspective of the user or
customer.

“Epic”
A large user story. 32
An example
As
As aa VP
VP Marketing,
Marketing, II want
want to
to
select
select the
the timeframe
timeframe to
to use
use when
when
reviewing
reviewing the
the performance
performance ofof past
past
promotional
promotional campaigns,
campaigns, so
so that
that II
can
can identify
identify and
and repeat
repeat profitable
profitable
As
As aa VP
VP Marketing,
Marketing, II want
want
ones.
ones.
to
to review
review the
the performance
performance
of
of historical
historical promotional
promotional Implementation-size stories;
campaigns
campaigns so so that
that II can
can days to implement
identify
identify and
and repeat
repeat As
As aa VP
VP Marketing,
Marketing, II can
can select
select
profitable
profitable ones.
ones. which
which type
type of
of campaigns
campaigns (direct
(direct
mail,
mail, TV,
TV, email,
email, radio,
radio, etc.)
etc.) to
to
A large user story;
include
include when
when reviewing
reviewing thethe
weeks to implement
performance
performance of of historical
historical
promotional
promotional campaigns.
campaigns.
33
An example
As
As aa VP
VP Marketing,
Marketing, II want
want to
to see
see
information
information on
on direct
direct mailings
mailings when
when
reviewing
reviewing historical
historical campaigns.
campaigns.

As
As aa VP
VP Marketing,
Marketing, II want
want to
to see
see
information
information on
on television
television advertising
advertising
when
when reviewing
reviewing historical
historical campaigns.
campaigns.

As
As aa VP
VP Marketing,
Marketing, II want
want to
to see
see
information
information on
on email
email advertising
advertising when
when
reviewing
reviewing historical
historical campaigns.
campaigns.
34
Story-writing workshops
• Includes developers, users, customer,
others
• Brainstorm to generate stories
• Goal is to write as many stories as
possible
¾ Some will be “implementation ready”
¾ Others will be “epic” user stories
• No prioritization at this point 35
Start with large user stories and
iterate As
As aa frequent
frequent flyer,
flyer,
II want
want to
to book
book aa
As
As aa frequent
frequent flyer, trip
flyer, trip using
using miles.
miles.
II want
want to
to see
see check
check
my
my account.
account.
As
As aa frequent
frequent flyer,
flyer,
II want
want to rebook aa
to rebook
As trip
trip II take
take often.
Frequent As aa frequent
frequent flyer,
flyer, often.
Frequent II want
want to
to book
book aa
flyer
flyer trip.
trip.
As
As aa frequent
frequent flyer,
flyer,
II want to request
want to request
an
an upgrade.
upgrade.
As
As aa frequent
frequent flyer,
flyer,
II want
want to
to ...
...

As
As aa frequent
frequent flyer,
flyer,
II want
want to see if my
to see if my
upgrade
upgrade cleared.
cleared.
36
For Your Project
Write the product backlog for your project.
• Identify your Users – 10 minutes
• Write some epics – 10 minutes
• 15 minutes:
• Write some large stories
• Write some ““implementation-ready”
implementation-ready” user
stories

Consider this template

“As a <type of user>, I want to <goal>, so
that <reason>.”
37
 What makes a good story?

Independent

Negotiable

Valuable
INVEST
Estimable

Sized Appropriately

Testable

38
Reproduced with kind permission by
Mike Cohn mountaingoatsoftware.com
11
Independent

• Dependencies lead to problems estimating and

prioritizing
• Can ideally select a story to work on without pulling in 18
other stories
22 Negotiable
• Stories are not contracts
• Leave or imply some flexibility

33 Valuable

• To users or customers, not developers

• Rewrite developer stories to reflect value to users or
customers

39
44
Estimatable
• Because plans are based on user stories, we need to be
able to estimate them

55
Sized Appropriately
• Small enough to complete in one sprint if you’re about to
work on it
• Bigger if further off on the horizon

66
Testable
• Testable so that you have a easy, binary way of knowing
whether a story is finished
• Done or not done; no “partially finished” or “done except”

40
Product Owner adds a feature
• You are the ScrumMaster for the team
developing the online dating website
• You are 3 months into a 6-month plan
• The team is halfway through a 2-week sprint
• The Product Owner comes to the you and
wants to add wedding planning features to the
dating site.In fact, the Product Owner has
scheduled a trade-show demo in two weeks.
You’ve never heard of this feature before
• What do you do?

41
Put all requirements in the PB

BUSINESS ENGINEERING RUN/SUPPORT

REQUIREMENTS REQUIREMENTS REQUIREMENTS
• User Stories •“Continuous Integration” • Deployment
• Bugs List • Complex Activity simplicity
• Performance • Tools implementation • Live service cost
• Capacity & BCP • Retrospective actions reduction

Product
Backlog
42
Values
Values for
Requirements Values for Customer
Company
Increase satisfaction
More users
Business Features, Stability,
More Revenue
Performance, Accessibility …

Increase satisfaction More users

Engineering
Quality, Stability, Faster delivery … More Revenue

Increase satisfaction Time and Money

Run/Support
Performance, Faster delivery … savings

43
Prioritization
• Ensure some requirements of each
category are in the Product Backlog

• Set up priorities in the Product Backlog to

ensure implementing some requirements
of each category for any release (one or
several sprints)

44
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

45
 e a se P l a nn i n g
Re l

46
Release Planning Exercise
Release Plan
2

V1.0 V1.1 V1.2

Sprint Sprint Sprint Sprint Sprints 5-7

1 2 3 4

V1.0 V1.1
Release Release

48
Release planning, not sprint planning

Drives
Multiple Sprints

Product Backlog

In To
Story To Do Process Verify Done
As a user, Code the... Test the... Code the... Test the... Code the...
I...As a user, Code the... Test the... DCCode the... SCTest the... DCCode the...
I... 9 8 4 DC 6 SC 4 Test
DC
the...
8 points SCTest the...
9 8 4 6 4
Code the... Code the... Test the... 8 SC
Test the...

M T W W Th F
8 points
Code the... Code the... SCTest the... SCTest
8
2 8 8 SC 6 SCTestthe...
the...
SC
2
Test the...
8
Test the... 8 6 6 Test
Testthe...
the...
SC
M 8
Test the...
4
Test the...
SCTest the...
66
SC
8 4 6

Drives Work As a user,

I...As a user,
5 points
I...
5 points
Code the...

8
8
Code the...

Code the...
Code the...
Test the...

8
8
Test the...

Code the...
Code the...
Code the...
DCCode the...
8 DC
8
Test the...
SCTest the...
6 SCTest the...
SC
6 6 Test
SC
Testthe...
SC
the...
6 6 Test the...
4 6 SC

on a Daily Basis 4 6
6

49
Sprint Task List
Release planning
Purpose
To answer questions such as:
• How much will be done by June 30?
• When can we ship with this set of features?
• How many people or teams should be on this
project?

Inputs
• Velocity
• The amount of work completed in a sprint
• The length of the project
• Prioritized product backlog
50
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

51
Product Backlog Estimating
6 minutes

8 minutes

1
kilometer

Team must agree on high-level estimate 52

Common product backlog
estimating units

Ideal Time

Calendar Time

53
Ideal Time -or- Calendar Time
Ideal time
• The amount of time something is likely to take one
person if they aren’t disrupted or distracted
• If two people will work on it, their time is added
• Often expressed in days (including ½ day, etc.)

Calendar Time
• Just old-fashioned guessing at the hours or days
something will take

54
Estimating in Scrum
• Product Backlog • Sprint Tasks
¾ Coarse-grained ¾ Hours
¾ Think: “Days” or ¾ 4-8 hour tasks
“Weeks”

55
Planning poker
• An iterative approach to estimating
• Steps
¾ Each estimator is given a deck of cards, each card
has a valid estimate written on it
¾ Customer/Product owner reads a story and it’s
discussed briefly
¾ Each estimator selects a card that’s his or her
estimate
¾ Cards are turned over so all can see them
¾ Discuss differences (especially outliers)
¾ Re-estimate until estimates converge 56
Planning poker - an example
5 8 1 3 20
3
1 2

Estimator Round 1 Round 2

Susan 3 5
Vadim 8 5
Ann 2 5
Chris 5 8
57
For Your Project
Estimate the user stories for your project
• Choose what units you will use to estimate
• Use planning poker

58
Estimate these
Product backlog item Estimate
Read a high-level, 10-page overview of agile software
development in a business magazine.

Read a densely written 5-page research paper about agile

software development in an academic journal.

Write the product backlog for a simple eCommerce site

that sells only clocks.

Recruit, interview, and hire a new member for your team.

Create a 60-minute presentation about agile estimating

and planning for your coworkers.

Read a 150-page book on agile software development.

Write an 8-page summary of this session for your boss.

59
Course agenda
Today
• Overview of Agile Planning
• High-Level Visioning
• Product Backlog
• User Stories
• Release Planning
• Estimating
• Velocity

60
Velocity
 Velocity is a measure of how much work we
can plan on completing each sprint

Product Backlog

62
Track velocity

40
Last Observation = 36
Mean (Last 8) = 33
30
Mean (Worst 3) = 28

20

10

0
1 2 3 4 5 6 7 8 9
Sprints 63
Velocity
• A useful long-term measure of the amount
of work completed per sprint
• Not a measure of the amount of work
completed in each sprint

Velocity is measured
in the units you use
to estimate product
backlog items

Sprints 64
Extrapolate from velocity

At our slowest velocity we’ll finish here

At our long-term average we’ll finish here

At current velocity we’ll finish here

65
Release planning
Release Planning
Meeting

Release Plan

Sprint 1 Sprint 2 Sprint 3 Sprints 4–7

66
An Agile Stance on Planning
• Recognize that change will happen
• Utilize feedback
• Ask for autonomous bits of functionality

67
Thank You!
Agile practices
 Agile engineering practices

1. Simple design
2. Continuous integration
3. Refactoring
4. Test-driven development

70
Reproduced with kind permission by
Mike Cohn mountaingoatsoftware.com
1. Simple design
• Safe steps
¾ Balance between efficiency and risk
¾ Small design and get feedback often

• Beneficially relating elements

• Design only for today
• If the future is uncertain, don’t code for it today
• Do not add infrastructure in this sprint for stories coming in
future sprints
¾ Upcoming stories could be cancelled or lowered in priority
• Do the simplest thing that can possibly work

71
2. Continuous integration
• An automated nightly build is a bare minimum for a Scrum
team
• Really want continuous integration:

ƒ Developer checks in code

ƒ Build server notices the check-in, waits to see if
more is coming
ƒ Builds the software
ƒ Runs a suite of automated tests
ƒ Emails results

• Products to help:
¾ Hudson, Cruise Control, and AntHill
72
Y!K development process with CI

Build (ant / buildcious)

run

Intg. Test (PhpUnit) testing

trigger

Document (PhpDocumentator)
CVS / Subversion / Perforce

commit
Coding Standard (CodeSniffer) Staging Environment
CI System
(Web / API / DB)
(php undercontrol)

Security (Scanmus, ferret)

report

Y!Developer Additional works

75
CI tools
• Php under control:
http://www.phpundercontrol.org/about.html

76
CI tools
• yHudson: https://hudson.dev.java.net

77
3. Test-Driven Development

ƒ Tests guide the completion of the

Acceptance Test- features worked on during a sprint
ƒ Started right at the beginning of the
Driven Development sprint
ƒ Refined throughout the sprint

ƒ Test guide the programmer during

the writing of code
Unit Test-Driven
ƒ Done a little at a time
Development ƒ Augmented throughout the sprint

78
Tests guide decisions

Unit tests guide decisions about

ƒ How to write the code
ƒ Which code is likely to change in the
future

Acceptance tests guide decisions about

ƒ Which parts of a feature should be implemented
ƒ In what order should the parts of a feature be
implemented
ƒ When is a feature done

79
Test-driven unit testing

Write a failing
test

Write code to
pass the test

Run the test to

verify the code
This cycle is very short
Minutes, not hours
81
Unit tests
• Low level tests to make sure a class or module
works as expected
• Almost always done by a programmer to his or her
own code
• Have become much more common over last five
years
¾ Increased popularity of the xUnit tools
• Allows a programmer to test by writing more code

• Are ideally done test-first

83
Unit tests
• Low level tests to make sure a class or module
works as expected
• Almost always done by a programmer to his or her
own code
• Have become much more common over last five
years
¾ Increased popularity of the xUnit tools
• Allows a programmer to test by writing more code

• Test module first then move to develop next module

¾ It can help to develop fast than debug whole code after
development
85
A frequent objection
• Why can’t I write my unit tests concurrently or right after my
code?
¾ You probably won’t; doing this takes more discipline than
writing them first

• You’ll consider some things “not testable with unit tests”

¾ Because testability wasn’t designed into them

• You’ll completely miss out on the evolutionary design benefits

¾ The tests won’t be as good
¾ You’ll be testing to say or show you did it; not writing tests that lead you to
the result
86
Test-driven acceptance tests
• Are specified by the product owner
¾ A tester can help, especially at first
¾ But only the product owner knows her expectations

• Are used to convey expectations about a feature

• Because product backlog items are lightweight and don’t

include details…
¾ …we need a way to pass along expectations about a product
backlog item
87
Iterate the tests, too!
• Just as we iterate over the meaning of a
requirement…
¾ …we iterate over the precision of a test

• We start with a simple test plan and then

simultaneously:
¾ Add more test cases
¾ Increase the precision of the test cases

88
4. Refactoring (design improvement)

• Refactoring
¾ Simplifying or improving the code without
changing its behavior
¾ It’s kind of rule of design for repeated changes
• Automated unit tests ensure nothing breaks
¾ Allows programmers to refactor with confidence
• “Always leave the code cleaner than you
found it.”
89
Thank you!