why plan? Reduce Risk Reduce Uncertainty Support Better Decision Making Establish Trust Convey 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 Parkinson’s Law states “Work expands so as to fill the time available for its completion” Lateness is passed down the schedule Activities are not independent
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
release planning DeﬁneConditions of SelectSatisfaction Iteration LengthGenerate Select Estimate User Stories User Stories Stories Estimate Release Date Velocity Prioritize User Stories
Conditions of satisfaction What is success? Date driven? Feature driven?
estimating size Desired Features Estimate Derive Schedule Size Duration 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 Fibonacci reflects the proportional uncertainty to estimate the further from the smallest you are. 1, 2, 4, 8 and 16 Still reflects non-linear pattern that highlights great uncertainty the further you get from the smallest.
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
prioritizing desirability Hotel Features Must Haves: Exciting: a bed built-in TV’s on treadmills a bathroom free bottled water in room a desk free hi-speed internet cleanThe More, the Better: comfort of the bed size of room variety of equip in ﬁtness room
kano model Threshold, or must-have, features Linear features Exciters and delighters
kano customer High Customer Satisfaction Exciters and delighters r ea lin c e/ Must-have, an Mandatory rm fo Implemented r Pe Low Fully Absent Feature Presence