Planningagile estimating & planning
your instructor              Derek              Neighbors              derek@integrumtech.com              @dneighbors
The Purpose of planning
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 ea...
Planning statistics  60% of projects significantly over run their  cost estimates  64% of features features included in  p...
planning by activity instead of feature     Activities don’t finish early  Parkinson’s Law states “Work expands so as to f...
additional traps we fall into    Multitasking causes further delays    Features are not developed by priority    We ignore...
the manifesto says...   Individuals and Interactions over Process and Tools   Working Software over Comprehensive Document...
an agile approach      Work as one team      Work in short iterations      Deliver something each iteration      Focus on ...
multiple levels of planning
release planning  DefineConditions     of                         SelectSatisfaction                  Iteration            ...
Conditions of satisfaction    What is success?    Date driven?    Feature driven?
estimating size Desired Features     Estimate      Derive                                      Schedule                Siz...
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 ar...
estimates are shared     Not done by “expert” individual     We don’t know WHO will do the work     Those not doing the wo...
estimation scales        1, 2, 3, 5, 8 and 13  Fibonacci reflects the proportional uncertainty to  estimate the further fr...
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         Average Length of Football Game?           15 min qtr x 4 = 60 minutes
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 ...
Workshop #1 In teams of 3 to 4 estimate (size) the following water vessels: row boat, canoe, speed boat, freight liner, cr...
probability distribution
epics & Themes     Blocks of Epics/Themes     Bigger numbers with same non-linear seq     More uncertainty     More likely...
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 ...
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 b...
select iteration length   Shorter times tightens feedback loops   Shorter times can feel like more overhead   Longer times...
derive duration Desired Features    Estimate    Derive                                   Schedule               Size     D...
estimate velocity   Yesterday’s weather   Sample week, averages   Sample sprint
velocity corrects estimation errors                          How Long to                          Paint?                  ...
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/significa...
value        Can be financial        Can be desirability
Cost       Cost can change depending on when       Can convert points to money
new knowledge                  High                       Low                     High                       Low High     ...
RiskHigh                                          High          High risk           High risk                             ...
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) ...
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         Hotel Features    Must Haves:             Exciting:     a bed                    built-i...
kano model     Threshold, or must-have, features     Linear features     Exciters and delighters
kano customer       High        Customer Satisfaction                                             Exciters and            ...
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 desir...
select stories and date   Feature driven.. Stories determines date   Date driven.. Date determines features   Can be detai...
release planning    Helps product owner and whole team   decide how long until release of product    Conveys expectations ...
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 bette...
splitting across data     Split stories along the boundaries of the    data supported by the story     Split exceptions or...
split on operational      Split large stories based on operations that    are performed within the story ex: search      S...
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 ...
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...
avoid temptation of related changes    Don’t add related changes    Unless related changes equivalent priority    “While I...
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.                   20m                       Activity ...
release burndown charts
release planning vs sprint planning    Use different scales (points / hours)    Use commitment driven approach
Upcoming SlideShare
Loading in …5
×

Agile Estimating and Planning

1,921 views

Published on

Agile planning.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,921
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
98
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile Estimating and Planning

  1. 1. Planningagile estimating & planning
  2. 2. your instructor Derek Neighbors derek@integrumtech.com @dneighbors
  3. 3. The Purpose of planning
  4. 4. why plan? Reduce Risk Reduce Uncertainty Support Better Decision Making Establish Trust Convey Information
  5. 5. what Makes a good plan? Sufficiently reliable for making decisions.
  6. 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. 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. 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. 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. 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. 11. an agile approach Work as one team Work in short iterations Deliver something each iteration Focus on business priorities Inspect and adapt
  12. 12. multiple levels of planning
  13. 13. release planning DefineConditions of SelectSatisfaction Iteration LengthGenerate Select Estimate User Stories User Stories Stories Estimate Release Date Velocity Prioritize User Stories
  14. 14. Conditions of satisfaction What is success? Date driven? Feature driven?
  15. 15. estimating size Desired Features Estimate Derive Schedule Size Duration Story Points
  16. 16. estimate stories Estimate gets to cost and time Not necessary to estimate everything always
  17. 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. 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. 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. 20. story points are relative 10 1
  21. 21. example Labrador - 5 Terrier - 3 Great Dane - 10 Toy Poodle - 1 German Shepard - 8 Bulldog - ???
  22. 22. estimating in ideal days Average Length of Football Game? 15 min qtr x 4 = 60 minutes
  23. 23. estimating size 5 Hours? 6 Wheel Barrows?
  24. 24. deriving an estimate Expert Opinion Analogy Disaggregation
  25. 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. 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. 27. probability distribution
  28. 28. epics & Themes Blocks of Epics/Themes Bigger numbers with same non-linear seq More uncertainty More likely estimates inaccurate
  29. 29. Why ideal days? Easier to explain outside team Easier to estimate at first (?)
  30. 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. 31. law of diminishing returns
  32. 32. when not to re-estimate Relativity is right, velocity wrong. Adjust velocity. Recalculate release.
  33. 33. when to re-estimate Relativity is wrong ex: API difficult to work with Adjust stories with API work
  34. 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. 35. select iteration length Shorter times tightens feedback loops Shorter times can feel like more overhead Longer times can be more comforting
  36. 36. derive duration Desired Features Estimate Derive Schedule Size Duration Velocity
  37. 37. estimate velocity Yesterday’s weather Sample week, averages Sample sprint
  38. 38. velocity corrects estimation errors How Long to Paint? What Size Rooms? 10’ x 12’ 20’ x 24’
  39. 39. prioritize stories Too little time, too many features Helps with decision making Helps reduce churn
  40. 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. 41. value Can be financial Can be desirability
  42. 42. Cost Cost can change depending on when Can convert points to money
  43. 43. new knowledge High Low High Low High HighEnd Uncertainty End Uncertainty (What) (What) Low Low Means Uncertainty Means Uncertainty (How) (How)
  44. 44. RiskHigh 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 valueLow Low Low Value High Low Value High
  45. 45. financial value Net Present Value Internal Rate of Return Payback Period Discounted Payback Period
  46. 46. theme return
  47. 47. revenue sources New (Customer / Markets) Incremental (New from Existing) Retained (Prevent Customers Leaving) Operation Efficiencies
  48. 48. Calculating new revenue
  49. 49. calculating incremental revenue
  50. 50. calculating retained revenue
  51. 51. calculating operational effeciencies
  52. 52. estimating development costs
  53. 53. putting it all together
  54. 54. net present value
  55. 55. internal rate of return
  56. 56. payback period
  57. 57. discounted payback
  58. 58. comparing returns
  59. 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 cleanThe More, the Better: comfort of the bed size of room variety of equip in fitness room
  60. 60. kano model Threshold, or must-have, features Linear features Exciters and delighters
  61. 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. 62. kano assessment
  63. 63. categorize responses
  64. 64. distribution of results
  65. 65. relative weighting
  66. 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. 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. 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. 69. extrapolating a plan using velocity
  70. 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. 71. splitting across data Split stories along the boundaries of the data supported by the story Split exceptions or error conditions
  72. 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. 73. remove cross-cutting concerns Remove from security, error handling, logging, etc
  74. 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. 75. mixed priorities Separate a large story into smaller stories if the smaller stories hae different priorities.
  76. 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. 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. 78. combining stories It’s okay to combine smaller stories Use caution and keep things managable
  79. 79. Workshop #2 In teams of 3 to 4 create a release plan using velocity. 20m Activity Time
  80. 80. release burndown charts
  81. 81. release planning vs sprint planning Use different scales (points / hours) Use commitment driven approach

×