Your SlideShare is downloading. ×
0
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Agile Estimating and Planning
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Estimating and Planning

1,401

Published on

Agile planning.

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,401
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
92
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Planningagile 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 DefineConditions of SelectSatisfaction Iteration LengthGenerate 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 HighEnd Uncertainty End Uncertainty (What) (What) Low Low Means Uncertainty Means Uncertainty (How) (How)
  • 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. 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 cleanThe 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

×