Agile Planning

g
n
i
t
a
m
i
t
s
E
Agile
and
g
n
i
n
n
a
l
P
Mike Cohn
m
o
c
.
e
r
a
w
t
f
tso
a
o
g
n
i
a
t
n
u
o
mike@m
0
1
0
2
,
8
e
Jun
Copyright
2009Mountain
MountainGoat
GoatSoftware
Software
Mike Cohn
Founding member and
director of Agile Alliance
and Scrum Alliance
Founder of Mountain
Goat Software
Doing Scrum since 1995
Started my career as a
programmer; worked as
VP Engineering in 4
companies
Copyright Mountain Goat Software
Scrum
24 hours
Sprint
2-4 weeks
Sprint goal
Return
Return
Cancel
Gift
Coupons
wrap
Gift
Cancel
wrap
Product
backlog
Sprint
backlog
Potentially shippable
product increment
Coupons
Whats a good plan?

A good plan is one that supports reliable
decision-making
Will go from
Well be done in the third quarter
Well be done in August
Well be done August 18th
Its better to be roughly right
than precisely wrong.
John Maynard Keynes
What makes planning agile?

Is more focused on
planning than the plan
Encourages change
Results in plans that are
easily changed
Is spread throughout the
project
Product, release, iteration planning

Release 1
Release 2
Release 3
Release Plan
Iteration 1 Iteration 2 Iteration 3
Iteration 47
Well focus
here today
Task A
Task B
Task C
Task D
8 hours
16 hours
5 hours
8 hours
Agenda
Product backlog estimation

units
Story points
Ideal time
Techniques for estimating

Iteration planning
Release planning
Product Backlog
Iteration Backlog
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
Code the UI
0C:E6E6DEUIEFC6
Code middle tier
12
Write tests
Automate tests
Were talking
about these
right now
How long will it take...

...to read the latest
Harry Potter book?
...to drive to
Milwaukee?
Estimate size; derive duration
Size
Calculation
Duration
300
kilograms
Velocity =
20
300/20 =
15 iterations
10
Measures of size
Traditional and agile measure size differently
Traditional
measures
of size
Lines of Code
Function Points
Agile
measures
of size
Story points
Ideal days
11
Story points
As a user, I want to be
The bigness of a task able to have some but not
#?VF6?4653J
all items in my cart gift
wrapped.
How hard it is
8
How much there is
Relative values are what is important:

A login screen is a 2.
A search feature is an 8.
Points are unit-less

Basic math properties should hold, e.g., 5+5 = 10
12
Dog points
Assign dog points to the following breeds.
Labrador retriever
Dachshund
Great Dane
Poodle
German Shepherd
Terrier
St. Bernard
Bulldog
13
One order of magnitude

Were good over one order of magnitude
So think about where to place it on your
product backlog
1

A typo
10
The largest
new feature
14
Agenda

units
Story points
Ideal time

Iteration planning
Release planning
15
Ideal time
How long something would take if
its all you worked on
you had no interruptions
and everything you need is available
The ideal time of a football game is 60

minutes
Four 15-minute quarters
The elapsed time is much longer (3+ hours)

16
Ideal time vs. elapsed time

Its easier to estimate in ideal time
Its too hard to estimate directly in elapsed
time
Need to consider all the factors that affect
elapsed time at the same time youre
estimating
17
Comparing the approaches

Story points help drive cross-functional behavior
Story point estimates do not decay
Story points are a pure measure of size
Estimating in story points is typically faster
My ideal days cannot be added to your ideal days
#562=52JD2C662D:6CE@6IA=2:?@FED:56E96E62>
#562=52JD2C662D:6CE@6DE:>2E62EUCDE
18
Three levels of planning

Release plan
Iteration plan
Daily
plan
Daily
plan
Daily
plan
Daily
plan
Iteration plan
Daily
plan
Daily
plan
19
three levels of precision

D27C6BF6?EVJ6C#
want to
30
3
D27C6BF6?EVJ6C#
want to
50
5
D27C6BF6?EVJ6C#
want to
50
5
D27C6BF6?EVJ6C#
want to
20
2
D27C6BF6?EVJ6C#
want to
20
2
Code the UI
0C:E6E6DEUIEFC6
Code middle tier
12
Write tests
Automate tests
Yesterday I started on the

.##D9@F=5U?:D9367@C6E96
end of today.
Copyright
2009Mountain
MountainGoat
GoatSoftware
Software
20
What I usually do
I prefer story points, but they make some teams
uncomfortable, so Ill
Start with ideal time
Gives the team a nice foundation for the initial stories
Helps team get started
6U?6R DE@CJA@:?E :562=52JS

Then
Gradually convert team to thinking in unit-less story points
This story is like that story.
Stop talking about how long it will take
21
Agenda

units
Story points
Ideal time

Iteration planning
Release planning
22
Estimate by analogy
Comparing a user story to others
This story is like that story, so its estimate is
what that storys estimate was.
Dont use a single gold standard

Triangulate instead
Compare the story being estimated to
multiple other stories
23
Triangulation
@?UC>6DE:>2E6D3J4@>A2C:?8E96DE@CJE@>F=E:A=6
other stories.
Group like-sized stories on table or whiteboard
3
points
Story A
2
points
Story C
Story D
1
point
Story B
Story E
Story F
24
Disaggregation
Breaking a big story into smaller stories or
tasks
You know how long the smaller tasks take
So, disaggregating to something you know lets
you estimate something bigger you dont know
Sometimes very useful

But disaggregating too far causes problems
Forgotten tasks
25
How much effort?

A little efforts helps a lot
Accuracy
A lot of effort only helps a little more
Effort
Copyright
2009Mountain
MountainGoat
GoatSoftware
Software
26
Use the right units

Can you distinguish a 1-point story from a 2?
How about a 17 from an 18?
Use a set of numbers that make sense; I like:

1, 2, 3, 5, 8, 13, 20, 40, 100
Stay mostly in a 1-10 range

Nature agrees:
Include 0
and if
you want
Musical tones and volume are distinguishable

on a logarithmic scale
27
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 its
5:D4FDD653C:6VJ
Each estimator selects a card thats his or her estimate
Cards are turned over so all can see them
Discuss differences (especially outliers)
Re-estimate until estimates converge
28
Planning
Poker 2?6I2>A=6
Estimator Round 1 Round 2

Susan
Vadim
Ann
Chris
8
29
Estimate these
Product backlog item
A
B
C
D
E
F
G
H
Estimate
Read a high-level, 10-page overview of agile software

development in People 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 software
development for your coworkers.
02D92?5H2IJ@FC3@DDT*@CD496
Read a 150-page book on agile software development.

Write an 8-page summary of this conference for your
boss.
30
Why Planning Poker works

Those who will do the work, estimate the
work1
Estimators are required to justify estimates2, 3
@4FD6D>@DE6DE:>2E6DH:E9:?2?2AAC@I:>2E6
one order of magnitude4, 5
1Jrgensen, Magne. 2004. A
Review of Studies on Expert Estimation of Software
Development Effort.
2Hagafors, R., and B. Brehmer. 1983. Does Having to Justify Ones Decisions Change
the Nature of the Decision Process?
3Brenner, et al. 1996. On the Evaluation of One-sided Evidence.
4Miranda, Eduardo. 2001. Improving Subjective Estimates Using Paired
Comparisons.
5Saaty, Thomas. 1996. Multicriteria Decision Making: The Analytic Hierarchy Process.
31
Why Planning Poker works

Combining of individual estimates6 through group
discussion7 leads to better estimates
Emphasizes relative rather than absolute estimating
Estimates are constrained to a set of values so we
dont waste time in meaningless arguments
Everyones opinion is heard
Its quick and fun
6Hoest, Martin, and
Claes Wohlin. 1998. An Experimental Study of Individual

Subjective Effort Estimations and Combinations of the Estimates.
7Jrgensen, Magne, and Kjetil Molkken. 2002. Combination of Software
Development Effort Prediction Intervals:Why,When and How?
32
www.PlanningPoker.com
Free,
or I
wouldnt
mention it
33
Agenda

units
Story points
Ideal time

Iteration planning
Release planning
34
Product Backlog
Iteration Backlog
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
D27C6BF6?EVJ6C#
want to
Creating this
D27C6BF6?EVJ6C#
5
want to list is iteration
Code the UI
0C:E6E6DEUIEFC6
Code middle tier
12
Write tests
Automate tests
Tasks
Hours
planning
35
Two approaches
1
Velocity-driven iteration planning
L R06U?:D965 DE@CJA@:?ED=2DEE:>6=6ETDA=2?@?
story points this time.
L Very unreliable in what will be accomplished during
an iteration
L Velocity is mostly useful over the long term
36
Commitment-driven iteration planning
L Discuss the highest priority item on the product

backlog
L Decompose it into tasks
L Estimate each task
L Whole team estimates each task
L Ask ourselves, Can we commit to this?
L If yes, see if we can add another backlog item
L If not, remove this item but see if we can add
another smaller one
37
Estimate personal availability

@CE96UCDE:E6C2E:@?DE2CE3J6DE:>2E:?8
how many hours each person has available
For later iterations, well make adjustments to
what we did this time rather than start over
Person
Hours/Day
Hours / Iteration
Sergey
46
4060
Yuri
57
5070
Carina
23
2030
Total
110160
38
It looks something like this

As a user, I want
2
L Code the abc class (8 hours)

L Code the user interface (4)
L 0C:E6E6DEUIEFC6D
L @56E96IJK4=2DD
L Update performance tests (4)
The team can commit, so they continue
As a user, I want
3
L Prototype the UI (8 hours)

L Demo UI to 3 outside users (3)
L Code new UI (12)
L Update documentation (3)
39
time
time
Copyright
2009Mountain
MountainGoat
GoatSoftware
Software
40
A caution
L The purpose of the iteration planning
meeting is to arrive at a commitment to

an iteration goal or set of product
backlog items.
L The purpose of the meeting is not to
come up with a list of tasks and hours.
L The tasks and estimates are a tool for

determining what we can commit to.
41
Agenda

units
Story points
Ideal time

Iteration planning
Release planning
42
Release planning
Release Planning Meeting
Release plan
Iterations
Iteration 1 Iteration 2 Iteration 3
47
43
Velocity
To do a release plan, you need to know or
have an estimate of velocity
Three ways to get velocity:
1. Use historical averages
2. Run 1-2 iterations and see what you get
3. Forecast it
,9@F=5366IAC6DD652D2C2?86
Size of range depends on familiarity of team,
domain, and technologies
44
Forecasting velocity
Just like commitment-driven iteration
planning
Estimate available hours for the iteration
Repeat until full:
Pick a story, break into tasks, estimate each task
45
?6I2>A=6
Available Hours /
Person Hours/Day
Iteration
Sergey
46
4060
Yuri
57
5070
Carina
23
2030
Total
To
110160
46
?6I2>A=6
What is the velocity if this team can
work 110160 hours per iteration?
Code
12
Design
Document
Decide
48
Analyze
Automate
22
Story
Points
As a frequent
VJ6C#H2?EE@P
As a visitor, I
can
As a vacation
planner, I can
22
As a frequent
VJ6C#H2?EE@P
Code
Test
31
Design
12
Test
48
48
47
Predicting release contents

Determine your median velocity
*FE24@?U56?46:?E6CG2=2C@F?5:E
Predicts best case and worst case
50
40
30
20
10
0
48
2=4F=2E624@?U56?46:?E6CG2=7C@>E96
teams historical velocity data.
Sorted Velocities
27
35
Median
38
39
40
40
41
45
4@?U56?46
interval
nth Highest
& Lowest
Iteration to
Use
11
13
16
18
21
23
26
.D6E96?6IE=@H6C?F>36C
of iterations if you dont have
2?6I24E?F>36C
34
# of
Historical
Iterations
Use the online velocity range calculator at

www.mountaingoatsoftware.com/tools
49
IEC2A@=2E67C@>E96G6=@4:EJC2?86
Assume:
There are five
iterations left.
Well almost certainly get here (534)

At our median velocity well get here (539)
-96>@DEH64@F=5C62=:DE:42==J6IA64E (541)
Copyright
2009Mountain
MountainGoat
GoatSoftware
Software
50
Mike Cohn
mike@mountaingoatsoftware.com
www.mountaingoatsoftware.com
twitter: mikewcohn
(720) 8906110
51

Agile 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

Agile Planning

Uploaded by

Copyright:

Available Formats

g

Copyright Mountain Goat Software

Whats a good plan?

What makes planning agile?

Copyright Mountain Goat Software

Product, release, iteration planning

Product backlog estimation

Techniques for estimating

Copyright Mountain Goat Software

Code middle tier

How long will it take...

Copyright Mountain Goat Software

Estimate size; derive duration

Copyright Mountain Goat Software

Copyright Mountain Goat Software

How much there is

Relative values are what is important:

Points are unit-less

Copyright Mountain Goat Software

One order of magnitude

Copyright Mountain Goat Software

Product backlog estimation

Techniques for estimating

Copyright Mountain Goat Software

The ideal time of a football game is 60

The elapsed time is much longer (3+ hours)

Ideal time vs. elapsed time

Copyright Mountain Goat Software

Comparing the approaches

Copyright Mountain Goat Software

Three levels of planning

Copyright Mountain Goat Software

three levels of precision

Code middle tier

Yesterday I started on the

6U?6R DE@CJA@:?E :562=52JS

Product backlog estimation

Techniques for estimating

Copyright Mountain Goat Software

Dont use a single gold standard

Copyright Mountain Goat Software

Copyright Mountain Goat Software

Sometimes very useful

How much effort?

A lot of effort only helps a little more

Use the right units

Use a set of numbers that make sense; I like:

Stay mostly in a 1-10 range

Musical tones and volume are distinguishable

An iterative approach to estimating

Estimator Round 1 Round 2

Read a high-level, 10-page overview of agile software

Read a 150-page book on agile software development.

Why Planning Poker works

Review of Studies on Expert Estimation of Software

Why Planning Poker works

Claes Wohlin. 1998. An Experimental Study of Individual

Product backlog estimation

Techniques for estimating

Copyright Mountain Goat Software

Code middle tier

Copyright Mountain Goat Software

Velocity-driven iteration planning

Copyright Mountain Goat Software

6U?6R DE@CJA@:?E :562=52JS