Upload
derek-neighbors
View
1.516
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Agile planning.
Citation preview
Planningagile estimating & planning
your instructor
[email protected]@dneighbors
The Purpose of planning
why plan?
Reduce RiskReduce UncertaintySupport Better Decision MakingEstablish TrustConvey Information
what Makes a good plan?
Sufficiently reliable for making decisions.
what makes planning agile?
Focused more on planning than the plan Encourages changes Results in plans that are easily changed Is spread throughout the project
Planning statistics
60% of projects significantly over run their cost estimates
64% of features features included in products are rarely or never used
The average project exceeds it’s estimate by 100%
planning by activity instead of feature
Activities don’t finish early
Lateness is passed down the schedule Activities are not independent
Parkinson’s Law states “Work expands so as to fill the time available for its completion”
additional traps we fall into
Multitasking causes further delays Features are not developed by priority We ignore uncertainty
Integrum Tip:Don’t split people among multiple projects.
Small iterations combat uncertainty.
the manifesto says...
Individuals and Interactions over Process and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
an agile approach
Work as one team Work in short iterations Deliver something each iteration Focus on business priorities Inspect and adapt
multiple levels of planning
release planning
GenerateUser
Stories
Estimate User Stories
Select IterationLength
EstimateVelocity
PrioritizeUser
Stories
SelectStories
Release Date
Define Conditions
ofSatisfaction
Conditions of satisfaction
What is success? Date driven? Feature driven?
estimating size
DesiredFeatures Estimate
SizeDerive
Duration Schedule
Story Points
estimate stories
Estimate gets to cost and time Not necessary to estimate everything always
estimates are Not commitments
An estimate is a probability Commitment can’t be made on probability Commitments are made to dates Estimates are not implicit commitments
estimates are shared
Not done by “expert” individual We don’t know WHO will do the work Those not doing the work still have the
ability to call bullshit
estimation scales
1, 2, 3, 5, 8 and 13
1, 2, 4, 8 and 16
Fibonacci reflects the proportional uncertainty to estimate the further from the smallest you are.
Still reflects non-linear pattern that highlights great uncertainty the further you get from the smallest.
story points are relative
10
1
example
Labrador - 5 Terrier - 3 Great Dane - 10 Toy Poodle - 1 German Shepard - 8 Bulldog - ???
estimating in ideal days
15 min qtr x 4 = 60 minutes
Average Length of Football Game?
estimating size
5 Hours?6 Wheel Barrows?
deriving an estimate
Expert Opinion Analogy Disaggregation
planning poker
Combines all three methods Quick but reliable Right amount of discussion (< 2 min) Smaller sessions Before project starts and within project
Workshop #1
In teams of 3 to 4 estimate (size) the following water vessels: row boat, canoe, speed boat, freight liner, cruise ship, yacht, sail boat using planning poker.
20mActivity Time
probability distribution
epics & Themes
Blocks of Epics/Themes Bigger numbers with same non-linear seq More uncertainty More likely estimates inaccurate
Why ideal days?
Easier to explain outside team Easier to estimate at first (?)
Why story points?
Help drive cross-functional behavior Do not decay Pure measure of size Typically faster to obtain estimate My ideal day is not your ideal day
law of diminishing returns
when not to re-estimate
Relativity is right, velocity wrong. Adjust velocity. Recalculate release.
when to re-estimate
Relativity is wrong ex: API difficult to work with Adjust stories with API work
re-estimate partially completed stories
No such thing as partially completed! Should only happen if so bad can’t be
completed in next 2 iterations Probably better to decompose and
estimate decomposed stories
select iteration length
Shorter times tightens feedback loops Shorter times can feel like more overhead Longer times can be more comforting
derive duration
DesiredFeatures Estimate
SizeDerive
Duration Schedule
Velocity
estimate velocity
Yesterday’s weather Sample week, averages Sample sprint
velocity corrects estimation errors
How Long to Paint?
What Size Rooms?
10’ x 12’
20’ x 24’
prioritize stories
Too little time, too many features Helps with decision making Helps reduce churn
factors in prioritization
The financial VALUE of having The COST of developing/supporting The amount/significance of NEW
KNOWLEDGE The amount of RISK removed
value
Can be financial Can be desirability
Cost
Cost can change depending on when Can convert points to money
new knowledge
High
High
Low
Low
Means Uncertainty(How)
End
Unc
erta
inty
(Wha
t)
High
LowMeans Uncertainty
(How)
End
Unc
erta
inty
(Wha
t)
High Low
Risk
High
High
Low
Low
Value
Ris
k
High
LowValue
Ris
kHighLow
High riskLow value
High riskHigh value
Low riskLow value
Low riskHigh value
Avoid Do first
Do SecondDo Last
financial value
Net Present Value Internal Rate of Return Payback Period Discounted Payback Period
theme return
revenue sources
New (Customer / Markets) Incremental (New from Existing) Retained (Prevent Customers Leaving) Operation Efficiencies
Calculating new revenue
calculating incremental revenue
calculating retained revenue
calculating operational effeciencies
estimating development costs
putting it all together
net present value
internal rate of return
payback period
discounted payback
comparing returns
prioritizing desirability
Must Haves:a beda bathrooma deskclean
The More, the Better:comfort of the bedsize of roomvariety of equip in fitness room
Exciting:built-in TV’s on treadmillsfree bottled water in roomfree hi-speed internet
Hotel Features
kano model
Threshold, or must-have, features Linear features Exciters and delighters
kano customer
Low
HighC
usto
mer
Sat
isfa
ctio
n
Abs
ent
Fully
Impl
emen
ted
Feature Presence
Perfo
rman
ce / l
inear
Must-have, Mandatory
Exciters anddelighters
kano assessment
categorize responses
distribution of results
relative weighting
Workshop #2
In teams of 3 to 4 prioritize the provided backlog using by value, cost, new knowledge, risk removed and desirability utilizing the methods show today.
45mActivity Time
select stories and date
Feature driven.. Stories determines date Date driven.. Date determines features Can be detailed by iteration Can be vague by iteration
release planning
Helps product owner and whole team decide how long until release of product Conveys expectations about what will be
developed Serves as a guidepost towards progress
extrapolating a plan using velocity
when to split a story
Too large to fit in an iteration Won’t fit in an iteration Story is Epic (needs better estimate)
splitting across data
Split stories along the boundaries of the data supported by the story Split exceptions or error conditions
split on operational
Split large stories based on operations that are performed within the story ex: search Split large stories into separate operations
(ex: CRUD)
remove cross-cutting concerns
Remove from security, error handling, logging, etc
don’t meet performance constraints
Consider splitting a large story by separating the functional and non functional aspects into separate stories. “Make it work. Then make it work faster.”
mixed priorities
Separate a large story into smaller stories if the smaller stories hae different priorities.
don’t split into tasks
Don’t split a large story into tasks. ex: Not UI, Model, Controller, View Story Use tracer bullets
avoid temptation of related changes
Don’t add related changes Unless related changes equivalent priority “While I’m in that code...” Only makes it worse
combining stories
It’s okay to combine smaller stories Use caution and keep things managable
Workshop #2
In teams of 3 to 4 create a release plan using velocity.
20mActivity Time
release burndown charts
release planning vs sprint planning
Use different scales (points / hours) Use commitment driven approach