Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Estimating and Planning

2,199 views

Published on

Agile planning.

Published in: Technology, Business
  • How can I get rid of my belly fat? ▲▲▲ https://tinyurl.com/y4j3grkc
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

×