Agile planning.

1. Planning
agile estimating & planning

2. your instructor
Derek
Neighbors
derek@integrumtech.com
@dneighbors

3. The Purpose of planning

4. why plan?
Reduce Risk
Reduce Uncertainty
Support Better Decision Making
Establish Trust
Convey Information

5. what Makes a good plan?
Sufficiently reliable for making decisions.

6. 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

7. 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%

8. 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

9. 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.

10. 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

11. an agile approach
Work as one team
Work in short iterations
Deliver something each iteration
Focus on business priorities
Inspect and adapt

12. multiple levels of planning

13. release planning
Define
Conditions
of Select
Satisfaction Iteration
Length
Generate Select
Estimate
User Stories
User Stories
Stories Estimate Release Date
Velocity
Prioritize
User
Stories

14. Conditions of satisfaction
What is success?
Date driven?
Feature driven?

15. estimating size
Desired
Features Estimate Derive
Schedule
Size Duration
Story Points

16. estimate stories
Estimate gets to cost and time
Not necessary to estimate everything always

17. 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

18. 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

19. 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.

20. story points are relative
10
1

21. example
Labrador - 5
Terrier - 3
Great Dane - 10
Toy Poodle - 1
German Shepard - 8
Bulldog - ???

22. estimating in ideal days
Average Length of Football Game?
15 min qtr x 4 = 60 minutes

23. estimating size
5 Hours?
6 Wheel Barrows?

24. deriving an estimate
Expert Opinion
Analogy
Disaggregation

25. planning poker
Combines all three methods
Quick but reliable
Right amount of discussion (< 2 min)
Smaller sessions
Before project starts and within project

26. 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.
20m
Activity Time

27. probability distribution

28. epics & Themes
Blocks of Epics/Themes
Bigger numbers with same non-linear seq
More uncertainty
More likely estimates inaccurate

29. Why ideal days?
Easier to explain outside team
Easier to estimate at first (?)

30. 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

31. law of diminishing returns

32. when not to re-estimate
Relativity is right, velocity wrong.
Adjust velocity. Recalculate release.

33. when to re-estimate
Relativity is wrong
ex: API difficult to work with
Adjust stories with API work

34. 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

35. select iteration length
Shorter times tightens feedback loops
Shorter times can feel like more overhead
Longer times can be more comforting

36. derive duration
Desired
Features Estimate Derive
Schedule
Size Duration
Velocity

37. estimate velocity
Yesterday’s weather
Sample week, averages
Sample sprint

38. velocity corrects estimation errors
How Long to
Paint?
What Size Rooms?
10’ x 12’
20’ x 24’

39. prioritize stories
Too little time, too many features
Helps with decision making
Helps reduce churn

40. factors in prioritization
The financial VALUE of having
The COST of developing/supporting
The amount/significance of NEW
KNOWLEDGE
The amount of RISK removed

41. value
Can be financial
Can be desirability

42. Cost
Cost can change depending on when
Can convert points to money

43. new knowledge
High Low High Low
High High
End Uncertainty
End Uncertainty
(What)
(What)
Low Low
Means Uncertainty Means Uncertainty
(How) (How)

44. Risk
High High
High risk High risk
Avoid Do first
Low value High value
Risk
Risk
Low risk Low risk
Do Last Do Second
Low value High value
Low Low
Low Value High Low Value High

45. financial value
Net Present Value
Internal Rate of Return
Payback Period
Discounted Payback Period

46. theme return

47. revenue sources
New (Customer / Markets)
Incremental (New from Existing)
Retained (Prevent Customers Leaving)
Operation Efficiencies

48. Calculating new revenue

49. calculating incremental revenue

50. calculating retained revenue

51. calculating operational effeciencies

52. estimating development costs

53. putting it all together

54. net present value

55. internal rate of return

56. payback period

57. discounted payback

58. comparing returns

59. 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
clean
The More, the Better:
comfort of the bed
size of room
variety of equip in fitness room

60. kano model
Threshold, or must-have, features
Linear features
Exciters and delighters

61. 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

62. kano assessment

63. categorize responses

64. distribution of results

65. relative weighting

66. 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.
45m
Activity Time

67. select stories and date
Feature driven.. Stories determines date
Date driven.. Date determines features
Can be detailed by iteration
Can be vague by iteration

68. 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

69. extrapolating a plan using velocity

70. when to split a story
Too large to fit in an iteration
Won’t fit in an iteration
Story is Epic (needs better estimate)

71. splitting across data
Split stories along the boundaries of the
data supported by the story
Split exceptions or error conditions

72. 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)

73. remove cross-cutting concerns
Remove from security, error handling,
logging, etc

74. 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.”

75. mixed priorities
Separate a large story into smaller stories if
the smaller stories hae different priorities.

76. don’t split into tasks
Don’t split a large story into tasks.
ex: Not UI, Model, Controller, View Story
Use tracer bullets

77. 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

78. combining stories
It’s okay to combine smaller stories
Use caution and keep things managable

79. Workshop #2
In teams of 3 to 4 create a release plan using velocity.
20m
Activity Time

80. release burndown charts

81. release planning vs sprint planning
Use different scales (points / hours)
Use commitment driven approach