Agile Planning

1
Agile Planning
Training Solutions
v. 7.7.1
2
Dilbert on Project Planning
3
Agenda

• Planning
• Planning Wisdom
• Traditional Planning
• Agile Planning
• 3 levels of Agile Planning
• Agile Release Planning
• Backlog Prioritization
• Story Sizing
• Creating the Release Plan
• Maintaining the Release Plan
• Agile Iteration Planning
• Commitment-base Iteration Planning
• Velocity-based Iteration Planning

4
Planning Wisdom

• A good plan executed now is better than a
  perfect plan executed next week.
• -General George S. Patton
• Planning is everything. Plans are nothing.
• -Helmuth Graf von Moltke (Prussian Field Marshal
  and strategic military thinker)
• If you tell people where to go, but not how to
  get there, youll be amazed at the results.
• -General George S. Patton

5
Why do some traditional plans fail?

• Planning by activity rather than by feature
• Lateness passed down schedule
• Multitasking
• Negative effects on productivity are typically
  not accounted for
• Features not developed by priority
• Important features often left until later and
  dropped if schedule not met
• Uncertainty is ignored
• Development is highly dynamic endeavor
• Estimates become commitments and are used against
  developers
• These usually start as guesstimates but later
  perceived as promises

6
Why do traditional plans fail?

• Parkinsons Law
• Work will fill the amount of time allotted to
  complete it
• Student Syndrome
• Work will not begin until the latest possible
  opportunity

To have ANY chance of doing better than plan,
developers must focus on completing task
immediately.
Traditional plans identify activities and
completion dates.
Task
Safety
Task
Safety
In reality, however, we procrastinate and dont
start the task until we feel there is just enough
time left to get it done
7
Planning to do our worst

• if all goes perfectly
• Activity based planning using Gantt charts allows
  us to only meet deadlines if all goes perfectly
• Adapts poorly to the reality
• Poor ability to adapt to changing situations
• Poor ability for targeted learnings
• Any slip in any task affects all subsequent tasks
• Assumes that a slippage is localized and atypical
• Activities will start as late as possible
  (Student Syndrome)
• Reduces ability to respond to change
• Using traditional planning methods, we are
  planning to do our worst

8
What is a good plan?

• A good plan is one that supports reliable
  decision-making
• One that increases in accuracy and precision over
  time
• Well be done in the fourth quarter
• Well be done in November
• Well be done November 7th

It is better to be roughly right than precisely
wrong. -John Maynard Keynes
9
What makes planning Agile?

• Focus on planning not the plan
• Balance benefit and investment
• Adaptive to change and learning
• Plans are easily changed
• Planning is continuous throughout the project

10
Different levels of planning
We will focus on these 3 planning areas
Strategy
Portfolio
Product
Release
Iteration
Day
11
3 Levels of Agile Planning
Release Planning
Iteration Planning
Daily Planning
Release Backlog (Stories)
Iteration Backlog (Tasks)
Iteration 1 As an investor, I want to 3
Iteration 1 As an investor, I want to 5
Iteration 2 As an investor, I want to 5
Iteration 2 As a visitor I want to 1
Iteration 2 As an investor, I want to 2
Iteration 3 As a visitor I want to 3
Iteration 3 As a visitor I want to 3
Iteration 3 An investor I want to 2
Define test cases 4
Code UI 8
Code middle tier 12
Code stored procedures 12
Automate tests 6
Daily Stand-up
Yesterday I started on the UI, I should finish
it today
12
Release Planning
13
Release Planning

• Q. What do we need to start Release Planning?

• A. List of prioritized stories
• aka. Release Backlog
• aka. Project Backlog
• aka. Product Backlog

The same techniques for a single release can be
applied to multiple releases to derive a
multi-release project plan
We dont need ALL possible stories just enough
to at least roughly fill the desired timeframe
Release Backlog

• Team Velocity
• Use Historical Values
• Use Actuals by running an iteration
• Forecast or Derive

Priority Story Size
1 As an investor, I want to
2 As an investor, I want to
3 As an investor, I want to
4 As a visitor I want to
5 As an investor, I want to
6 As a visitor I want to
7 As a visitor I want to
8 An investor I want to
14
Prioritization
15
Prioritization Factors

• Financial Value of stories/features
• Assign dollar-value to stories or features
• Cost of implementing (or not implementing!)
  stories/features
• Consider cost now vs. cost of adding later
• Also consider opportunity costs
• Amount and significance of learning and new
  knowledge created by the stories/features
• Project (how?)
• Product (what?)
• Amount of risk removed by developing the
  stories/features
• Reduced project or product uncertainty
• Prioritize across Themes or Features
  individual stories that cannot clearly be valued

NoteAs long as the Product Owner is considering
all these things appropriately, there is no need
to formalize or overcomplicate prioritization
16
Risk

• Anything that might happen that would jeopardize
  or limit the success of the project.
• Types of Project Risk
• Schedule Risk
• We might not be done by October 21
• Cost Risk
• We dont have budget for more consultants
• Functionality Risk
• We might not be able to develop
  sufficiently-flexible roles-based access

NoteThough technically Risks can have
positive as well as negative impacts on projects
however typically the word Risk is not used
to describe possible positive effects. As such,
we will focus on the negative impact of Risk.
17
Risk-Value Prioritization
These likely arent worth doing EVER.

• Which stories should we work on first?

Tackle high-risk areas with big return.
High
High Risk Low Value
High Risk High Value
Risk
Low Risk High Value
Low Risk Low Value
Low
Low
High
Value
18
More about Prioritization

• Financial
• New Revenue, Incremental Rev, Operating
  Efficiencies
• Net Present Value, Internal Rate of Return,
  Payback Period, Discounted Payback Period
• Desirability
• Must-haves
• The More, the Better
• Exciters

MoSCoW Prioritization Technique Must Haves -
Fundamental to the projects success oShould
Haves - Important but the projects success does
not rely on these Could Haves - Can easily be
left out without impacting on the projectoWon't
Have - This time round can be left out this time
and done at a later date
The indispensable first step to getting what
you want is this Decide what you want. -Ben
Stein
19
Story Sizing
20
Imagine

• You are fed up with software development
• And you decide go into the landscaping business

• Your first job
• Move this pile of rock from the front of my
  house to the back
• How do we estimate how long?

21
How might you estimate this?

• One way
• Look at the pile of rock and estimate how many
  wheelbarrow loads it represents
• After an hour, see how many wheelbarrow loads
  have moved
• Extrapolate the total duration

• I think thats 100 wheelbarrow loads
• After an hour Ive moved 20 loads
• So, I should be done in a total of 5 hours

22
Estimate Size Derive Duration
23
Sizing Release/Product Backlog
Product Backlog (Stories)
Iteration Backlog (Tasks)
Iteration 1 As an investor, I want to 3
Iteration 1 As an investor, I want to 5
Iteration 2 As an investor, I want to 5
Iteration 2 As a visitor I want to 1
Iteration 2 As an investor, I want to 2
Iteration 3 As a visitor I want to 3
Iteration 3 As a visitor I want to 3
Iteration 3 An investor I want to 2
Define test cases 4
Code UI 8
Code middle tier 12
Code stored procedures 12
Automate tests 6
24
Measures of Size

• Traditional and Agile measure size differently

• Traditional Measures of Size
• Lines of Code
• Function Points

• Agile Measures of Size
• Ideal Time
• Story Points

If you tell people where to go, but not how to
get there, youll be amazed at the
results. -General George S. Patton
25
Ideal Time

• How long would something take if
• Its all you worked on
• You had no interruptions
• Everything you need is readily available
• The Ideal time of a football game is 60 Minutes
• 4 x 15-minute quarters
• The elapsed time is much longer (3 hours)
• Shortcomings of sizing with Ideal Time
• My ideal days cannot be added to your ideal days
• Ideal days are often confusing and misleading
  because they do not represent duration
• Ideal Time is dependent on the implementer

26
Elapsed time vs. ideal time
Ideally

• Monday has 8 hours
• Each week has 40 hours

• Monday has
• 3 hours of meetings
• 1 hour of email
• 4 hours left for project

Instead
This developer will only make 4 hours of progress
on Monday It will take two calendar days to
complete one ideal day of work

• How long will this take?
• Are you answering what is being asked?

27
Story Points

• The bigness of a task
• Influenced by
• How hard it is
• How much of it there is
• Relative values are what is important
• A login screen is a 2
• A search feature is an 8
• Points are unit-less

28
More on Story Points

• Approach for starting the sizing process
• Assign 1 to smallest story or Assign 5 to a
  medium story
• Size others by comparison/analogy
• Alternative Small-Medium-Large-XL
• Benefits
• Point sizes never decay
• Sizes dont change based on estimator
• Are independent of the implementer
• Measure of size, not duration
• Encourage cross-functional behavior
• Shortcomings
• Can be difficult to get started
• Must estimate initial velocity (but you can
  easily get it after 1 iteration)

Problem with T-Shirt SizingRelative relationship
between sizes is lost. Example How much bigger
is a Large than a Medium?
29
Point Sizing Units

• A 1-point and 2-point story are easily
  distinguishable
• The 2-point story will be twice the size of the
  1-point story
• A 17 and 18 story are not very distinguishable
• Whats the difference between 17 and 18 anyways?
• Use units that make sense
• 1, 2, 3, 5, 8
• 1, 2, 4, 8
• Include 0 and ½ if desired

30
Exercise Fruit Points

• Use Fruit Points to size the following breeds

watermelon orange blueberry cranberry strawberry a
pple grapefruit bananapearpeach

• Suggestion
• Assign 1 to smallest story or Assign 5 to a
  medium story
• Estimate size of others by comparison/analogy

31
Approaches to Sizing

• Estimates are made by a GROUP not an INDIVIDUAL
• Use a consistent relative scale
• Combine techniques
• Expert Opinion
• Analogy
• Disaggregation or Decomposition
• Planning Poker

32
Estimate by Analogy

• Comparing an un-sized story to previously sized
  stories
• This story is like Story 5, so it has the same
  number of points
• Triangulate
• Compare the story to multiple previously sizes
  stories not just one
• This story is the same size as Story A and Story
  B. Both A and B are 5 points, so this story is
  also 5 points

33
Consider these two
34
Disaggregation/Decomposition

• Breaking big stories into smaller stories
• Goal is to define stories that can fit into
  single iterations
• Dont spend too much time
• A little effort helps a lot
• A lot of effort only helps only a little more

At some point, extra effort decomposing actually
reduces accuracy (See Critical Chain Project
Management reference)
35
Planning Poker

• What is it?
• It is a tool to facilitate group sizing
• What do you need?
• Entire team including product owner/customer
• Deck of planning poker cards with point sizes
• Stories

36
Planning Poker How to Play?

• Each team member is given a deck of cards each
  card has a point size written on it
• Customer/Product-Owner reads a story
• Customer must be knowledgeable enough to discuss
  each story
• The story is briefly discussed, questions
  answered etc.
• The discussion should be sufficient to determine
  the complexity and relative size of the work
• Compare story to other, previously sized stories
• Use analogy and triangulation techniques
• Each team member secretly selects a card that is
  his or her estimate
• Sizes should be presented together
• Cards are presented to the group at the same time
• Each persons opinion is represented
• Differences and outliers are discussed
• Discuss why some people think a story is bigger
  than what other people think
• Re-estimate until estimates converge
• Sometimes the exercise needs to be time-boxed
• Sometimes some negotiation is needed Meet the
  size half-way
• If 1 person is a holdout, but is very close ? Ask
  them if the consensus is agreeable

37
Planning Poker an example
As a user, I want to be able to have some but not
all items in my cart gift wrapped
Round 1 Round 2
Jill 3 5
Bob 8 5
Yang 2 5
Ann 5 8
Todd 5 5
Result Story Size 5 Points
38
Exercise Remodeling my Kitchen

• In groups Size in Kitchen Points using
  planning poker the following stories
• Install new hardwood floor
• Refinish (remove, sand, repaint) the cabinets
• Replace my tile countertop with granite
• Repaint entire kitchen
• Lay shelf paper
• Install recessed lighting
• Replace electric stove with gas stove
• Install a new oven
• Plumb the island and add sink

39
Why Planning Poker Works?

• Emphasizes relative estimating
• Focuses most estimates with an approximate one
  order or magnitude
• Everyones opinion is heard
• Estimators are required to justify sizes
• Its quick
• Its fun

40
Velocity a quick reminder

• The rate of work completion
• The amount of sized work completed in an
  iteration
• The number of points per iteration

41
Release Planning
Product Backlog
Release Planning Meeting
Release Plan
Iteration 1
Iteration 2
Iterations 3-6
42
Example (Velocity 21 Points)
Iteration 1
Iteration 3-6
Story A
Story D
Story E
Story F
Story K
Story B
Story B
5
8
5
13
5
5
3
Story I
Story M
Story O
2
8
13
Iteration 2
Story J
Story P
Story N
Story C
Story H
1
5
8
Story G
Story L
Story Q
Story R
8
8
5
13
8
3
43
Updating the Release Plan

• Revisit the release plan at the end of every
  iteration
• Agile planning is continuous and adaptive
• Update plan based on
• Current understanding of velocity
• Current prioritization of backlog
• Should take little time but highly effective

44
Release Plan Updating Example
Initial Release Plan forecasted an iteration
velocity of 16 points. The Release schedule
allows for 3 iterations. At Velocity of 16, the
forecasted story points to be delivered by the
release is approximately 48.
During Iteration 1, on 13 points were completed.
Therefore, the release plan can be updated to
reflect the new velocity.
Story A 5
Story C 5
Story G 3
Story D 3
Story K 5
Story B 5
Story E 3
Story F 3
Story J 2
Story H 5
Story I 5
Story L 3
Story A 5
Story C 5
Story G 3
Story D 3
Story K 5
Story B 5
Story E 3
Story F 3
Story J 2
Story H 5
Story I 5
Story L 3
v
With a lower iteration velocity, fewer stories
are now planned for however, as these are
prioritized lower on the backlog they offer the
least value
Iteration 1
v
Iteration 1
v
Iteration 2
Iteration 2
Iteration 3
Iteration 3
45
Multiple views of Velocity
Last Iteration 36
Mean 36
Mean (worst 3) 29
Worst 25
46
Extrapolate Release Scope from Velocity
At our slowest velocity well finish here
At our current velocity well finish here
At our long-term average velocity well finish
here
47
Exercise Update the Release Plan
Here are the results of the last 8 iterations.
There are 6 iterations left. Using this data,
update the release plan by drawing 3 arrows into
it
Running Total Points Story
5 5 Story A
10 5 Story G
23 13 Story D
31 8 Story K
51 20 Story B
59 8 Story E
64 5 Story F
72 8 Story J
77 5 Story H
85 8 Story I
90 5 Story L
93 3 Story M
48
A Final Notes on Story Points and Velocity

• Story points are specific to a team and product
• Points from one teams backlog cannot be compared
  to another teams backlog comparing Apples to
  Oranges
• Velocity is dependent on points and therefore
  cannot be compared across teams

If you want a guarantee, buy a toaster.
Clint Eastwood in The Rookie
49
Iteration Planning
Product Backlog (Stories)
Iteration Backlog (Tasks)
Iteration 1 As an investor, I want to 3
Iteration 1 As an investor, I want to 5
Iteration 2 As an investor, I want to 5
Iteration 2 As a visitor I want to 1
Iteration 2 As an investor, I want to 2
Iteration 3 As a visitor I want to 3
Iteration 3 As a visitor I want to 3
Iteration 3 An investor I want to 2
Define test cases 4
Code UI 8
Code middle tier 12
Code stored procedures 12
Automate tests 6
We are talking about these right now
50
2 Approaches to Iteration Planning

• Commitment-driven iteration planning
• How much are we, as a team, willing to commit
  to?
• Velocity-driven iteration planning
• We finished 20 story points last time, lets
  plan on 15 story points this time

51
Commitment-driven Iteration Planning

• Discuss the highest priority item on the product
  backlog
• Decompose it into tasks
• Estimate each task (in hours)
• Ask Can we commit to this?
• If yes, see if another backlog item can be added
• If not, remove this item but see if we can add
  another smaller one
• Shortcomings of Commitment-Driven Iteration
  Planning
• Cannot perform longer-term planning
• Risk of Parkinsons Law

52
Velocity-driven Iteration Planning
It is sometimes helpful to determine an objective
for the iteration At the end of the iteration I
want to show
Do in any sequence
Adjust Priorities
Estimate Tasks(in hours)
Identify Tasks
Select Stories
Determine Target Velocity
Do not try to have the total estimated hours
equal to the iteration capacity.
53
Agile Planning Lifecycle Summary
Product Vision
ProductBacklog
Scrum/Stand-up
Release Planning
Iteration Planning
ProductDevelopment
Budget
Schedule
Velocity
Product Increment
54
References

• This presentation is based directly on the book
  Agile Estimation and Planning by Mike Cohn-
  this book is highly recommended for anyone who
  intends to do estimation and planning on agile
  projects.
• Other References Used in this Deck
• Agile Estimation and Planning George Schlitz.
  Presentation Material
• Agile Estimation and Planning Mike Cohn.
  Presentation/Training Material
• Planning and Tracking on Agile Projects Mike
  Cohn. Presentation Material
• Estimation Games Rob Thomsett. An article
  about common bad estimation games and
  antipatterns (http//www.thomsett.com.au/main/arti
  cles/hot/games.htm)