agile project planning - scrum training project planning.pdf · workshop agile project planning...
TRANSCRIPT
1
1
Agile Project Planning~
Erik Philippus
©IMPROVEMENT BV workshop agile project planning
2
workshop agile project planning
• 65% of projects significantly overrun their cost estimates• 65% of product features are rarely or never used• the average project exceeds its schedule by 100%
Much work remains to be done before we can announce our failure to make progress
Traditional PlanningA Joyless Track Record
2
3
workshop agile project planning
Traditional PlanningCauses of Planning Failure
• Planning is by activity rather than feature- Parkinson's Law
• Lateness is passed down the schedule- Antipattern: Anti-gravity Module
• Multitasking causes further delays- assigning work to individuals rather than to groups
- focus on high level of utilization of all individuals
• Features are not developed by priority- dropped features may be of greater value
than those that are delivered
• Uncertainty is not acknowledged- product specifications are generally imperfect or incomplete - assignment of precise estimates to imprecise work- estimates become commitments
4
workshop agile project planning
Parkinson's Law
Work expands so as to fill the time available for its completion.
The Colonial Office had its greatest number of staff at the point when there was a lack of colonies to administer.
Forces:
1 An official wants to multiply subordinates, not rivals2 Officials make work for each other
Colonial Office, London
3
5
workshop agile project planning
Organizational Pattern:
Anti-gravity Module
Risky components are scheduled to be completed last.
“The launch module is 98% built -
all we need is the antigravity module.”
avoid do first
do seconddo last
low
low
high
high
risk
value
6
Agile PlanningDealing with Uncertainty
anticipation
adaptation
plan
actadapt
flexibility to adapt to
changing business conditions
absolute conformance
to original plans
workshop agile project planning
4
7
Agile Planning Principle #1:
Apply Multiple Levels of Planning
workshop agile project planning
dayportfolio sprintreleaseproduct
focus of agile teamstrategic planning
2 - 3 months 2 weeks 1 day
8
Relating the Planning Levels
workshop agile project planning
Release 1 Release 2 Release 3
release plan
sprint 1 sprint 2 sprint 3 - 6
task A 4 hourstask B 6 hourstask C 3 hourstask D 8 hours
5
9
Relating the Planning Levels
workshop agile project planning
as a …., I want to ….
as a …., I want to ….
as a …., I want to ….
as a …., I want to ….
as a …., I want to ….
as a …., I want to ….
as a …., I want to ….
as a …., I want to ….
2
5
1
4
6
2
3
1
itera
tion 2
itera
tion 1
task A
task B
task C
task D
task E
task F
task G
6 hours
4 hours
5 hours
12 hours
2 hours
6 hours
5 hours
yesterday, I started to work on ….
and I should finish before the end of today
product backlog sprint backlog
daily scrum
10
workshop agile project planning
Conditions of satisfaction
(user stories, budget, schedule)
ReleasePlanning
Conditions of satisfaction
(user stories, acceptance tests)
Product Increment
SprintPlanning
release
sprint
feedback
Conditions of SatisfactionDrivers for Release and Sprint Planning
6
11
workshop agile project planning
Agile Planning Principle #2:
Use a Relative Measure of Size
traditional measures of size
function pointslines of code
agile measures of size
story points
12
workshop agile project planning
Estimating Sizeexample
I'd like 14 ounces of soda, 6 ounces of lasagna, and 3 ounces of bread
7
13
workshop agile project planning
Estimating Sizeexample
I'd like a large soda, a medium size lasagna, and
a small serving of bread
14
workshop agile project planning
Story Points
Story Points are a unit of measure for expressing the overall size of a piece of work using relative values.
Story Points are a measurement of complexity and/or size of a requirement as compared to
the duration to complete that requirement.
Story Points are used for planning and tracking
on release-level
8
15
workshop agile project planning
Assignment of Story Pointsexercise
Assign
'Zoo Points'
to the following
breeds:
16
workshop agile project planning
Assignment of Story Pointsexercise
Breed Zoo Points
LionKangarooRhinocerusBearGiraffeGorillaHippopotamusTiger
9
17
workshop agile project planning
• Forces the use of relative estimatingstudies have shown that we're better at relative estimating (over one order of magnitude) rather than absolute estimating
• Help to drive cross-functional behavior
• Focuses us on the size, not the durationderive duration emperically
• Puts estimates in units we can add togetherstory points are unit-lesstime-based estimates are not additive
Story Pointskey advantages
18
workshop agile project planning
Elapsed TimeOverall amount of time that passes on a clock or calendar
Ideal TimeAmount of time something takeswhen stripped of all peripheral activities
Salvadore Dali ~ Persistance of Time
It is easier and more accurate to predict the durationof an event in ideal time than in elapsed time
Ideal TimeAlternative for Story Points
10
19
workshop agile project planning
meetingsdemo'sphone callsspecial projectstraininge-mailreviewsbug fixingsupportsick time…
typically, you are able to work ten minutes between interruptions
Interruptions
20
workshop agile project planning
1. The story being estimated is the only thing you'll work on2. Everything you need will be on hand when you start3. There will be no interruptions
When estimating in ideal days, you assume:
In favor of ideal days:
- Ideal days are easier to explain outside the team- Ideal days are necessary/easier to estimate at first
However, the preference is for story points!
Estimation in Ideal Days
11
21
workshop agile project planning
Agile Architecting
How long will it take …
• to read the latest Harry Potter book?
• to drive from Amsterdam to Maastricht?
Velocityexamples
22
workshop agile project planning
Velocity is a measure of a team's rate of progress
It is calculated by summing the number of story points assigned to each user story
that the team completed during the iteration
Team Velocity
12
23
workshop agile project planning
Agile Planning Principle #3:
Let Velocity take care of Estimation Errors
Velocity corrects most estimation inaccuracies
The correctness of estimates isn't crucialWhat matters is that they are consistent
24
workshop agile project planning
Estimation of Velocity
• Use historical values• Run an iteration• Make a forecast
The cone of uncertainty
0.6x
1.6x
x
0.8x
1.25x
iterations low high completed multiplier multiplier
1 0.60 1.602 0.80 1.253 0.85 1.154 or more 0.90 1.10
Express estimations as a range! bad time for estimation
better time for realistic estimations
13
25
workshop agile project planning
Determining Velocity
1517 18
20
12
20
15
19
iterations
observ
ed v
elo
city
mean (last eight)
mean (worst three)
last
26
workshop agile project planning
Forecasting Velocity
Step 1 Estimate the numbers of hours that each person will be available to work on the project each day
- typically 4 - 6 hours/day for a full-time assignment
Step 2Determine the total number of hours that will be spenton the project during the iteration
Step 3Find a representative set of stories, and expand them into tasks.Estimate each task in ideal hours.Repeat until you have identified enough tasks to fill the iteration.
Step 4Convert the velocity determined in step 3 into a range
14
27
workshop agile project planning
Re-Estimation
golden rule:re-estimate only when the relative size of one or more user stories has changed
Do not re-estimate solely because progress is not
coming as rapidly as you'd expected
28
workshop agile project planning
ESTIMATION OF OF EFFORT
ESTIMATION OF DURATION
story points
+
velocity
Agile Planning Principle #4:
Estimate Size, but Derive Duration
15
29
workshop agile project planning
• Utilize collaborate estimates
• Prefer estimations by those who will do the work
• Use an appropriate estimation scale
• Remove all (political) bias from the estimate
Agile Estimation in Practice
additional estimation effort yields little value beyond a certain point
accura
cy
100
50
effort
30
workshop agile project planning
Use the Right Units
can you distinct a 1-point story from a 2?and a 17 from an 18?
you need an ever growing scale
• 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) include 0
and 1/2 if
you want
fibonacci sequence
16
31
workshop agile project planning
Planning Poker
1 All the team members have a set of cards
2 Moderator reads description of the backlog item
3 Everyone selects and simultaneously shows cards
4 If estimates vary significantly, high and low estimators brieflyexplain their estimates
5 Repeat steps 3-4 until estimates stop converging
6 Decide estimate for backlog item
7 Move to next backlog item
32
workshop agile project planning
Planning PokerExercise
User Stories
As a Software Engineer, I want to have a basic version of the specification, sufficient to assess the potentialpotential of the application
As an Art Worker, I want to have a basic version of the specification, sufficient to develop the artwork for the mockup
As a Software Engineer , I want to have specification of the product configuration for the upcoming release
As a Product Development Manager, I want to have proof that the application will run without problems in the final product environment
ID
1.6
1.7
2.10
3.7
Estimation(ideal days)
?
?
?
?
17
33
workshop agile project planning
Plannign Pokerwhy it works
• Combining individual estimates throughgroup discussion leads to better estimates
- estimators are required to justify estimates
• Emphasizes relative rather than absolute estimating- focuses most estimates within an
approximate one order of magnitude
• Estimates are constrained to a set of values,so we don't waste time in meaningless arguments
• Everyone's opinion is heard- those who will do the work, estimate the work!
• It's quick and fun
see www.planningpoker.comfor planning poker for distributed teams
34
workshop agile project planning
Prioritizing User Stories
• The financial value of having the feature• The cost of developing / supporting the new feature• The amount and signficance of learning and new knowledge
created by developing the feature• The amount of risk removed by developing the feature• The business impact of not having the feature
Guidelines for prioritizing user stories or themes:
18
35
workshop agile project planning
Relative Penalty
Golden Rule:Incorporate the relative penalty
in your prioritization
Look at features from the perspective of how users will be affected by the presence as well
as by the absence of the feature
36
workshop agile project planning
Relative Weighting
Rela
tive B
enefit
Rela
tive P
enalty
Tota
l Valu
e
Valu
e %
Estim
ate
Cost
%
Pri
ori
ty
Feature
uploading pictures 8 6 14 42 32 53 0.8
3D touchscreen 9 2 11 33 21 34 1.0
voice recognition 3 5 8 25 8 13 1.9
Total 20 13 33 100 61 100
19
37
workshop agile project planning
exciters anddelighters
must-have,mandatory
perfo
rman
ce/li
near
Feature Presenceabsent fullyimplemented
Custo
mer
Satisfa
ction
low
high
unspoken
unspoken
indifferent
Desirability of FeaturesKano Model
38
workshop agile project planning
Paired Questions
If you can upload photo's with your mobile,
how do you feel?
If you cannot upload photo's with your mobile,
how do you feel?
functional form:
dysfunctional form:
+
-
I expect it to be that way X
I am neutral
I dislike it that way
I expect it to be that way
XI am neutral
I dislike it that way
20
39
workshop agile project planning
Differentiating Product Features
Feature Implemented
Feature Absent
Don't Like Neutral Expect
Don't Like
Neutral
Expect
user perception
indifferent delighter
linearmust-be
reversereverse
reverse
skeptical
skeptical
40
workshop agile project planning
Trackingrelease burn-down chart
250
200
150
100
50
01 2 3 4 5 6 7 8
240-point projectcompleted in 8 sprints
sto
ry p
oin
ts
sprint
21
41
workshop agile project planning
Trackingrelease burn-down chart
250
200
150
100
50
01 2 3 4 5 6 7 8
240-point projectcompleted in 8 iterations
sto
ry p
oin
ts
sprint
240-point projectcompleted in 8 iterations
Burn down charts:• Raise questions, they
don't answer them• Facilitate early discussions• Make it impossible to lie
42
workshop agile project planning
TrackingRelease Burn-down Bar
sprints
sto
ry p
oin
ts
0
-50
300
work is completed
new work is added
work isremoved
work is re-estimated
22
43
workshop agile project planning
Multiple-team Projects
Planning a complex projects with many interteam dependencies may require:
• establishing a common basis for estimates- story points or ideal time
• adding detail to the user stories sooner- allows multiple teams to coordinate work
• performing lookahead planning- maintaining a rolling lookahead window
during release and iteration planning
• incoporating feeding buffers into the plan- preventing late start of a team caused by
a late delivery of another team
44
workshop agile project planning
Release Planning
Determineconditions ofsatisfaction
Estimate theuser stories
Select sprintlength
Estimatevelocity
Prioritizeuser stories
Select storiesand a
release date
do in anysequence
iterate until the conditionsof satisfaction for the
release can best be met
5-10 iteratons2-5 months
combination ofschedule, scope
resources
estimation instory points
23
45
workshop agile project planning
Sprint Planning
AdjustPriorities
Determinetarget
velocity
Select userstories
do in anysequence
Identifysprintgoal
Split userstories
into tasks
EstimateTasks
equals mostrecent velocity(for new teams,
forecast velocity)
estimation inideal hours
1 sprint2-4 weeks
ask team forcommitment
46
workshop agile project planning
Strategic Planningproduct backlog 1 quarter ahead
quarter
start of upcoming sprint
updated launch planwith rough estimations
product backlog with prioritized
user story estimations
24
47
Agile Architecting
Agile Project Planning8 reasons why it works
Agile Architecting Essentials - Agile Estimation & Planning
• Estimates of size and duration are separated- translate story points into duration using velocity
• Plans are made at different levels- 3 different levels/perspectives: release, sprint, daily
• Plans are based on features, not tasks- focus on product that must be built
• Small stories keep work flowing- short cycle times will deliver value as fast as possible
• Work in progress is eliminated every sprint- no high amounts of work in progress, 'Kanban' principle
• Tracking is at the team level- buidling commitment; elimination of the 'blame game'
• Uncertainty is acknowledged and planned for- express uncertainty in either the functionality or the date
48
Agile Architecting
References
Agile Architecting Essentials - Agile Estimation & Planning
1 Mike CohnAgile Estimating and Planning, Prentice Hall, 2007
2 Todd Little:Software Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty, IEEE Software, May 2006, Vol. 23, No. 3
3 Kent Beck and Martin Fowler Planning Extreme Programming, Addison-Wesley, 2001
4 George D. Githens Rolling Wave Project Planning, 1998http://www.catalystpm.com/NP02.PDF