Date post: | 29-Dec-2015 |
Category: |
Documents |
Upload: | bruno-hutchinson |
View: | 213 times |
Download: | 0 times |
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Training Solutions
Agile Planning
v. 7.12.1
Agile Planningand Planning
2
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Dilbert on Project Planning
Agile Planningand Planning
3
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
Agile Planningand Planning
4
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Only 16% of projects finished on-time, on-budget with originally defined scope
Most traditional plans fail…Most traditional plans fail…
Only 16% of projects are delivered…On-Time…On-Budget…All defined scope…
Source: Standish Report, 1994
Agile Planningand Planning
5
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
►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
►Highly dependent on early, error-prone estimates Traditional plans are typically estimate-driven
Why do traditional plans fail?
Agile Planningand Planning
6
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
300100160
Estimating Troubles
Impact of Client Expectations on Estimates
No Info
GROUP 1
Con
trol
hours
Estimate:
40 hours
GROUP 2
Low
hours
told:
Estimate:
GROUP 3
Hig
h
hours
800 hourstold:
Estimate:
Experienced software developers were divided into 3 groups Group 1 – Not told about client opinion Group 2 – Told that client believed a low level of effort was required Group 3 – Told that client believed a high level of effort was required All groups were told to ignore client opinions and expectations
Source: Jorgenen & Grimstad, 2007. How to Avoid Impact from Irrelevant and Misleading information when estimating software development effort
Agile Planningand Planning
7
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Estimating Troubles
Impact of Irrelevant Information on Estimates
Experienced software developers were divided into 2 groups Both groups given the same requirements and instructions Group 1 – No additional information provided Group 2 – Provided with irrelevant information
• example: systems with which they do not need to integrate with Asked to estimate the work
2 X
Est
imat
e (H
ours
)
Group 2Group 1
Source: Jorgenen & Grimstad, 2007. How to Avoid Impact from Irrelevant and Misleading information when estimating software development effort
Agile Planningand Planning
8
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
4025
Estimating Troubles
Handling Irrelevant Information
Source: Jorgenen & Grimstad, 2007. How to Avoid Impact from Irrelevant and Misleading information when estimating software development effort
No Irrelevant Info
GROUP 1
Con
trol
hours
Estimate:
HiddenIrrelevant Info
GROUP 2
Hid
den
hours
Estimate:
3540
HighlightIrrelevant Info
GROUP 3
Iden
tify
hours
Estimate:
GROUP 4
Rem
ove
hours
Estimate:
RemoveIrrelevant Info
Agile Planningand Planning
9
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
►Parkinson’s Law Work will fill the amount of time allotted to complete it
►Student Syndrome Work will not begin until the latest possible opportunity
Why do traditional plans fail?
Task Safety
To have ANY chance of doing better than plan, developers must focus on completing task immediately.
Traditional plans identify activities and completion dates.
TaskSafety
In reality, however, we procrastinate and don’t start the task until we feel there is just enough time left to get it done
Agile Planningand Planning
10
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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”
Agile Planningand Planning
11
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
What is a good plan?
► A good plan is one that supports reliable decision-making
► One that increases in accuracy and precision over time We’ll be done in the fourth quarter We’ll be done in November We’ll be done November 7th
“It is better to be roughly right than precisely wrong.”
-John Maynard Keynes
“It is better to be roughly right than precisely wrong.”
-John Maynard Keynes
Agile Planningand Planning
12
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
► 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
What makes planning Agile?
Agile Planningand Planning
13
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Different levels of planning
Strategy
Portfolio
Product
Release
Iteration
Day
We will focus on these 3 planning areas
Agile Planningand Planning
14
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Release Planning
Agile Planningand Planning
15
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Release Planning
Q. What do we need to start Release Planning?
A. List of prioritized, sized 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
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…
Release Backlog
We don’t need ALL possible stories – just enough to at least roughly fill the desired timeframe
Team Velocity Use Historical Values Use Actuals by running an iteration Forecast or Derive
Agile Planningand Planning
16
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Prioritization
Agile Planningand Planning
17
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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”
Note:As long as the Product Owner is considering all these things appropriately, there is no need to formalize or overcomplicate prioritization
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
18
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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 don’t have budget for more consultants”
► Functionality Risk “We might not be able to develop sufficiently-flexible roles-based access”
Note:Though 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”.
Agile Planningand Planning
19
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Risk-Value Prioritization
Which stories should we work on first?
High Risk
Low Value
High Risk
High Value
Low Risk
High Value
Low Risk
Low Value
Ris
k
Value
High
LowLow High
Tackle high-risk areas with big return.
These likely aren’t worth doing EVER.
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
20
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
“The indispensable first step to getting what you want is this: Decide what you want.”
-Ben Stein
“The indispensable first step to getting what you want is this: Decide what you want.”
-Ben Stein
MoSCoW Prioritization TechniqueMust Haves - Fundamental to the projects success o
Should Haves - Important but the projects success does not rely on these Could Haves - Can easily be left out without impacting on the projecto
Won't Have - This time round can be left out this time and done at a later date
MoSCoW Prioritization TechniqueMust Haves - Fundamental to the projects success o
Should Haves - Important but the projects success does not rely on these Could Haves - Can easily be left out without impacting on the projecto
Won't Have - This time round can be left out this time and done at a later date
Agile Planningand Planning
21
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Imagine…
► You are fed up with software
► And you decide go into professional house-painting business
► Your first job:
Paint the Exterior of This House
How do we estimate how long this would take??
Agile Planningand Planning
22
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
How might you estimate this?
► One way: Estimate the exterior surface size Begin painting After an hour, see how much has
been painted Extrapolate the total duration
• I think that’s approximately 2,500² ft• After an hour I’ve painted 250² ft• So, I should be done in a total of 10 hours
• I think that’s approximately 2,500² ft• After an hour I’ve painted 250² ft• So, I should be done in a total of 10 hours
Agile Planningand Planning
23
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Estimate Size – Derive Duration
SizeSize Velocity Calculation
Velocity Calculation DurationDuration
250 pounds250 pounds Velocity = 50 PoundsVelocity = 50 Pounds
250/50 = 5 trips
250/50 = 5 trips
120story points
120story points
Velocity = 20 PointsVelocity = 20 Points
120/20 = 6 Iterations
120/20 = 6 Iterations
Agile Planningand Planning
24
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Sizing Release/Product Backlog
Iteration
1
As an investor, I want to…
3
As an investor, I want to…
5
Iteration
2
As an investor, I want to…
5
As a visitor I want to…
1
As an investor, I want to…
2
Iteration
3
As a visitor I want to…
3
As a visitor I want to…
3
An investor I want to…
2
Product Backlog (Stories)
Define test cases 4
Code UI 8
Code middle tier 12
Code stored procedures
12
Automate tests 6
Iteration Backlog (Tasks)
Story Points orIdeal Days
Hours
We are talking about these
right now
Agile Planningand Planning
25
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Measures of Size
► Traditional Measures of Size Lines of Code Function Points
► Agile Measures of Size Ideal Time Story Points
► Traditional and Agile measure size differently
“If you tell people where to go, but not how to get there, you’ll be amazed at the results.”
-General George S. Patton
“If you tell people where to go, but not how to get there, you’ll be amazed at the results.”
-General George S. Patton
Agile Planningand Planning
26
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Ideal Time
► How long would something take if: It’s 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
Agile Planningand Planning
27
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Elapsed time vs. ideal time
IdeallyIdeally• Monday has 8 hours• Each week has 40 hours• Monday has 8 hours• Each week has 40 hours
InsteadInsteadMonday has:• 3 hours of meetings• 1 hour of email• 4 hours left for project
Monday has:• 3 hours of meetings• 1 hour of email• 4 hours left for project
This developer will only make 4 hours of progress
on Monday
It will take two calendar days to complete one ideal
day of work
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?
“How long will this take?”
Are you answering what is being asked?
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
28
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
As a user, I want to be able to have some but not all items in my cart
gift wrapped
As a user, I want to be able to have some but not all items in my cart
gift wrapped 55
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
29
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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 don’t 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?
Instructor Says:I recommend using Story Points. Most agile projects are using storypoints.
Instructor Says:I recommend using Story Points. Most agile projects are using storypoints.
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
30
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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 What’s 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
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
31
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Exercise: Fruit Points
► Use “Fruit Points” to size the following fruits:
watermelonorange
blueberrygrape
strawberryapple
grapefruitbanana
pearpeach
watermelonorange
blueberrygrape
strawberryapple
grapefruitbanana
pearpeach
Suggestion• Assign 1 to smallest story or Assign
5 to a “medium” story• Estimate size of others by
comparison/analogy
Agile Planningand Planning
32
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
33
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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”
StoryA
StoryA
StoryB
StoryB
StoryE
StoryE
StoryC
StoryC
StoryD
StoryD
StoryF
StoryF
3pts
5pts
8pts
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
34
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Consider these two
Agile Planningand Planning
35
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Disaggregation/Decomposition
► Breaking big stories into smaller stories
► Goal is to define stories that can fit into single iterations
► Don’t spend too much time A little effort helps a lot A lot of effort only helps only a little more
Effort
Acc
ura
cy
100
50
At some point, extra effort decomposing actually reduces accuracy (See Critical Chain Project Management reference)
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
36
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
Agile Planningand Planning
37
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Planning Poker – How to Play?
1. Each team member is given a deck of cards – each card has a point size written on it
2. Customer/Product-Owner reads a story► Customer must be knowledgeable enough to discuss each story
3. The story is briefly discussed, questions answered etc.► The discussion should be sufficient to determine the complexity and relative size of the work
4. Compare story to other, previously sized stories► Use analogy and triangulation techniques
5. Each team member secretly selects a card that is his or her estimate► Sizes should be presented together
6. Cards are presented to the group at the same time► Each person’s opinion is represented
7. Differences and outliers are discussed► Discuss why some people think a story is bigger than what other people think
8. Re-estimate until estimates converge► Sometimes the exercise needs to be time-boxed► Sometimes some negotiation is needed – “Meet the size half-way”
9. If 1 person is a holdout, but is very close Ask them if the consensus is agreeable
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
38
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Planning Poker – an example:
As a user, I want to be able to have some but not all items in my cart
gift wrapped
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
Agile Planningand Planning
39
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
40
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Why Planning Poker Works?
► Emphasizes relative estimating
► Focuses most estimates with an approximate one order or magnitude
► Everyone’s opinion is heard
► Estimators are required to justify sizes
► It’s quick
► It’s fun
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
41
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Velocity – a quick reminder
► The rate of work completion
► The amount of sized work completed in an iteration
► The number of points per iteration
Agile Planningand Planning
42
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Release Planning
Product Backlog
Release Planning WorkshopRelease Planning Workshop
Iteration 1
Iteration 2
Iterations 3-6
Release Plan
# Story Priority Size2 As a user, I want to… 1 25 As a user, I want to… 2 38 As a user, I want to… 3 23 As a user, I want to… 4 316 As a user, I want to… 5 519 As a user, I want to… 6 51 As a user, I want to… 7 213 As a user, I want to… 8 39 As a user, I want to… 9 521 As a user, I want to… 10 122 As a user, I want to… 11 26 As a user, I want to… 12 57 As a user, I want to… 13 310 As a user, I want to… 14 115 As a user, I want to… 15 531 As a user, I want to… 16 832 As a user, I want to… 17 323 As a user, I want to… 18 524 As a user, I want to… 19 733 As a user, I want to… 20 14 As a user, I want to… 21 511 As a user, I want to… 22 312 As a user, I want to… 23 814 As a user, I want to… 24 127 As a user, I want to… 25 229 As a user, I want to… 26 228 As a user, I want to… 27 235 As a user, I want to… 28 536 As a user, I want to… 29 525 As a user, I want to… 30 326 As a user, I want to… 31 230 As a user, I want to… 32 5
# Story Priority Size2 As a user, I want to… 1 25 As a user, I want to… 2 38 As a user, I want to… 3 23 As a user, I want to… 4 3
# Story Priority Size16 As a user, I want to… 5 519 As a user, I want to… 6 5
# Story Priority Size1 As a user, I want to… 7 213 As a user, I want to… 8 39 As a user, I want to… 9 521 As a user, I want to… 10 122 As a user, I want to… 11 26 As a user, I want to… 12 57 As a user, I want to… 13 310 As a user, I want to… 14 115 As a user, I want to… 15 531 As a user, I want to… 16 832 As a user, I want to… 17 3
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
43
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Story C
Story G
Example (Velocity = 21 Points)
Story A
5Story B
3
Story D
8Story S
5
Iteration 1
Iteration 2
8
Story H
8
5
Iteration 3-6
Story E
5
Story I
2
Story J
1
Story L
13
Story F
13
Story M
8
Story P
5
Story Q
8
Story K
5
Story O
13
Story N
8
Story R
3
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
44
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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
Agile Planningand Planning
45
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Release Plan Updating Example
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
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.
Ite
ratio
n 1
Ite
ratio
n 2
Ite
ratio
n 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 3It
era
tion
1It
era
tion
2It
era
tion
3
√√√
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
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
46
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
0
10
20
30
40
1 2 3 4 5 6 7 8 9
Multiple views of Velocity
Last Iteration = 36
Mean = 31
Mean (worst 3) = 29
Worst = 25
Iteration
Vel
oci
ty (
po
ints
)
Source: Mike Cohn, Agile Planning and Planning
Agile Planningand Planning
47
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Extrapolate Release Scope from Velocity
At our slowest velocity we’ll finish here
At our current velocity we’ll finish here
At our long-term average velocity we’ll finish here
# Story Priority Size2 As a user, I want to… 1 25 As a user, I want to… 2 38 As a user, I want to… 3 23 As a user, I want to… 4 316 As a user, I want to… 5 519 As a user, I want to… 6 51 As a user, I want to… 7 213 As a user, I want to… 8 39 As a user, I want to… 9 521 As a user, I want to… 10 122 As a user, I want to… 11 26 As a user, I want to… 12 57 As a user, I want to… 13 310 As a user, I want to… 14 115 As a user, I want to… 15 531 As a user, I want to… 16 832 As a user, I want to… 17 323 As a user, I want to… 18 524 As a user, I want to… 19 733 As a user, I want to… 20 14 As a user, I want to… 21 511 As a user, I want to… 22 312 As a user, I want to… 23 814 As a user, I want to… 24 127 As a user, I want to… 25 229 As a user, I want to… 26 228 As a user, I want to… 27 235 As a user, I want to… 28 536 As a user, I want to… 29 525 As a user, I want to… 30 326 As a user, I want to… 31 230 As a user, I want to… 32 5
Agile Planningand Planning
48
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
15
9
2022
8
13
19
14
0
10
20
30
1 2 3 4 5 6 7 8
Velo
city
Iterations
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
Exercise: Update the Release Plan
Last Iteration =
Long-term average = 15
Mean of worst 3 =
14 14 * 6 = 84
15 * 6 = 9010 10 * 6 = 60
Last
Average
Worst 3
Agile Planningand Planning
49
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
A Final Notes on Story Points and Velocity
► Story points are specific to a team and product
► Points from one team’s backlog cannot be compared to another team’s 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
“If you want a guarantee, buy a toaster.” – Clint Eastwood in The Rookie
Agile Planningand Planning
50
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Iteration Planning
Iteration
1
As an investor, I want to…
3
As an investor, I want to…
5
Iteration
2
As an investor, I want to…
5
As a visitor I want to…
1
As an investor, I want to…
2
Iteration
3
As a visitor I want to…
3
As a visitor I want to…
3
An investor I want to…
2
Product Backlog (Stories)
Define test cases 4
Code UI 8
Code middle tier 12
Code stored procedures
12
Automate tests 6
Iteration Backlog (Tasks)
We are talking about these
right now
Agile Planningand Planning
51
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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, let’s plan on 15 story points this time”
Agile Planningand Planning
52
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
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 Parkinson’s Law
Agile Planningand Planning
53
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Velocity-driven Iteration Planning
Adjust Priorities
Determine Target Velocity
Do in any sequence
Estimate Tasks(in hours)
IdentifyTasks
Select Stories
It is sometimes helpful to determine an objective for the iteration“At the end of the iteration I want to show…”
Do not try to have the total estimated hours equal to the iteration capacity.
Agile Planningand Planning
54
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
Agile Planning Lifecycle Summary
Budget
Schedule
Scrum/Stand-up
Product Increment
Velocity
Agile Planningand Planning
55
____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____
Click to edit Master text stylesSecond levelThird levelFourth levelFifth level
(c) 2007 Copyright BigVisible Solutions. All Rights Reserved
References
This presentation is based on the book “Agile Planning 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 Planning 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/articles/hot/games.htm)