Download to read offline
Uploaded byJonathon Hill
Estimation Protips - NCDevCon 2014
Jonathon Hill's presentation at NCDevCon discusses effective software estimation techniques, emphasizing that estimates should not be seen as promises and must account for inherent uncertainties. He outlines several pro tips for accurate estimations, including the dangers of premature estimation and the disadvantages of large teams. Additionally, he recommends using historical data for proxy estimations and stresses the importance of thorough planning to avoid pitfalls like scope creep and inflated time projections.
More Related Content
Similar to Estimation Protips - NCDevCon 2014
![[HCM Scrum Breakfast] Agile estimation - Story points](https://cdn.slidesharecdn.com/ss_thumbnails/storypointsestimations-160827052054-thumbnail.jpg?width=640&height=640&fit=bounds)
Estimation Protips - NCDevCon 2014
- 1. ESTIMATION PROTIPS JONATHONHILL NCDEVCON, SEPT. 2014
- 2. BACKGROUND • Self-taught • 5+ years of full-time development • Former CTO for a small web startup • Former Director of Development for a digital marketing agency • AtlantaPHP Steering Committee
- 6. I DID ITWRONG
- 7. PROTIP #1: ESTIMATESARE NOT PROMISES
- 8. (N) ES-TIM-ATE: Anattempt to quantify something in the face of the unknown. By definition, estimates are imprecise and tentative, versus
- 9. “GOOD” ESTIMATE Agood estimation approach should provide estimates that are within 25% of the actual results 75% of the time. Conte, Dunsmore, and Shen (1986)
- 10. CERTAINTY Sadly, peopleasking for control or visibility really want certainty. Which doesn’t exist. Dan North https://twitter.com/tastapod/status/116271851767992320
- 11. DISTINCTIONS Target: astated desirable business objective Commitment: a promise to deliver a specific product within a specific timeframe
- 13. DEFINITION A goodestimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit targets. Steve McConnell, Software Estimation
- 14. PROTIP #2: YOURGUT LIES
- 16. HEAVIEST BLUE WHALEEVER RECORDED 380,000 LBS
- 17.
- 18.
- 19. HOFSTADTER’S LAW “Italways takes longer than you expect, even when you take into account Hofstadter’s Law.” Douglas Hofstadter Gödel, Escher, Bach: An Eternal Golden Braid
- 20.
- 22. IT’LL BE DIFFERENT THIS TIME!
- 23. THE PLANNING FALLACY Students estimated their senior thesis completion time in a 1994 study: 27.4 33.9 48.6 55.5 60 50 40 30 20 10 0 Best Case Expected Case Worst Case Actual Source: Wikipedia
- 25. TIME FRAMES “Withsoftware estimation you've only realistically got a choice of 5 mins, 1 hour, 1-2 days, about a week, and then all bets are off.” Rob Bowley https://twitter.com/robbowley/status/115430969825181696
- 26. TIME FRAMES Canit be done in… • 5 minutes? • 1 hour? • 1-2 days? • 1 week?
- 27. PROTIP #3: PREMATURE ESTIMATION IS SABOTAGE
- 28. DEFINITION A goodestimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit targets. Steve McConnell, Software Estimation
- 29.
- 30. OVERESTIMATION • Inflatedprices – might lose the job • Lack of urgency – project time fills up the estimate when it could have been done faster • Procrastination
- 31. UNDERESTIMATION • Inadequateplanning • Missed deadlines • Overwork, burnout • More bugs • Technical debt • Damage control • Unplanned interim releases • Meetings proliferate
- 33. IS IT USEFUL? If there’s as much chance of you coming up with something meaningful by rolling some dice or rubbing the estimate goat then what purpose are you satisfying by doing so? Rob Bowley
- 34. PROTIP #4: BIGTEAMS ARE SLOWER THAN SMALL ONES
- 36. TIME = ESTIMATE ÷ AVAILABILITY
- 41. TEAM EFFICIENCY DevelopersCommunication Paths Individual Efficiency Team Capacity 1 0 100% 1x 2 3 75% 1.5x 3 6 67% 2x 4 10 63% 2.5x 5 15 60% 3x 6 21 58% 3.5x 7 28 57% 4x 8 36 56% 4.5x 9 45 56% 5x 10 55 55% 5.5x Source: Paul M. Jones, http://paul-m-jones.com/archives/1591
- 42. PROTIP #5: BEWARE UNWARRANTED PRECISION
- 43. “533.5 hours” vs “13 workdays” vs “3 weeks”
- 45. PROTIP #6: COUNTALL THE THINGS!
- 46. TIME FRAMES Canit be done in… • 5 minutes? • 1 hour? • 1-2 days? • 1 week?
- 47. DECOMPOSITION AND RECOMPOSITION 1. List all the features 2. Break the features into sub-features 3. Break the sub-features into components 4. Estimate the components 5. Add the estimates up
- 48. LAW OF LARGENUMBERS The tendency for errors on the high side and errors on the low side to cancel each other out. i.e., The accuracy of the sum is greater than the accuracy of the individual estimates.
- 49. PAUL JONES’ METHOD 1. List all the controllers required for each feature 2. List all the methods required for each controller 3. Estimate 1 dev-pair day per controller method
- 50. BRANDMOVERS METHOD 1.List all the logical features required 2. Break down each feature into small logical components 3. List all the pages and modals required for each feature 4. Estimate the back-end time required for each logical component 5. Estimate the front-end time required for each page 6. Sum up the back-end and front-end totals
- 52. PROTIP #7: WHENIN A PINCH, USE A PROXY
- 53. PROXY ESTIMATION 1.Assign a size classification to each feature 2. Compute the average time required for similarly-sized features from actual past projects 3. Create estimate ranges for each feature based on past performance 4. Sum the result
- 54. PROS • Easier • Faster
- 55. CONS • Lessaccurate • Requires collection and archival of project historical data on a per-feature basis
- 56. STORY POINTS •Uses a point scale: 1, 2, 4, 8, 16 • Break down the project into epics and stories • Assign a point value to each story • Schedule releases at regular intervals • The number of points completed per release is known as “velocity” • Use the velocity to plan and estimate the delivery dates for future releases
- 57. EXAMPLE Iteration 1 • 27 story points delivered • 12 staff weeks expended over 3 calendar weeks • Effort = 27 points / 12 weeks = 2.25 points/week • Schedule = 27 points / 3 weeks = 9 points/week Iteration 2 projection • 33 story points scheduled • Effort = 33 points / 2.25 points/week = 15 staff weeks • Schedule = 33 points / 9 points/week = 4 calendar weeks
- 59. T-SHIRT SIZING •Assign a T-shirt size for development cost • Assign a T-shirt size for business value • Create a table of business value to development cost ratios • Look up the net business value for each feature based on the dev cost and business value T-shirt sizes • Prioritize the features in order of net business value
- 60. EXAMPLE Feature BusinessValue Dev Cost Feature A L S Feature B S L Feature C L L Feature D M M Feature E M L
- 61. VALUE TO COSTRATIOS Development Cost XL L M S XL 0 4 6 7 L -4 0 2 3 M -6 -2 0 1 S -7 -3 -1 0 Business Value
- 62. BIZ VALUE EXAMPLE Feature Business Value Dev Cost Net Value Feature A L S 3 Feature C L L 0 Feature D M M 0 Feature E M L -2 Feature B S L -3
- 63. PROTIP #8: YOUCAN’T NEGOTIATE MATH
- 65. PROBLEM SOLVING Whenthe estimate and target conflict: • Negotiate features • Negotiate time • Negotiate price
- 66. ATTITUDE • Tryto be helpful, offer solutions • Be creative • Examine what can be done in parallel to save time • Be firm – you can’t change the laws of physics
- 67.
- 68. ONE FINAL WORD A HORROR STORY
- 69. THE SETTING •Former employer of mine • Start-up, naïve and inexperienced • Needed cash bad
- 70. THE CLIENT •Small company in Atlanta • Four separate disconnected systems • Wanted web-based workflow consolidation • Wanted online ordering and payments
- 71. THE ESTIMATE •Estimated at 1,039 man-hours • Normal hourly rate was $120/hr • We did a fixed-bid for $50k, at an effective hourly rate of $48/hr
- 72. THE FALLOUT •18 months later… • 2,500 man-hours • 1,500+ Subversion commits • Lots of “unknown unknowns”, hidden complexities, and scope creep
- 73. THE MORAL •Don’t succumb to optimism or planning bias • Use a good estimation methodology • Try not to do fixed bidding • Always have a thorough scope before starting
- 74. ESTIMATION PROTIPS 1.Estimates are not promises 2. Your gut lies 3. Premature estimation is sabotage 4. Big teams are slower than small ones 5. Beware unwarranted precision 6. Count all the things! 7. When in a pinch, use a proxy 8. You can’t negotiate math
- 75. JonathonHill.net @compwright BookRecommendation: Software Estimation: Demystifying the Black Art by Steve McConnell
Editor's Notes
- #11 Dan North sez…
- #12 Targets: “We need v2.1 ready to demo at a trade show in May.” “Our budget is $2mm, we must limit the cost of the next release to that budget.”
- #13 Here’s the problem: estimates and targets often collide. Good estimates are probability statements based on what is known about the project and available resources, and targets are specific business objects that are sometimes quite solid. At Brandmovers, if we’re building a promotion to help generate buzz and excitement for the next Avengers movie, and that movie launches on a particular date, it isn’t really an option to delay launching the promotion if the project runs over. So if an estimate isn’t a promise, what is a good estimate?
- #15 Ever been asked for a “gut estimate?” It’s not at all uncommon to be asked to estimate something about which you have next to no knowledge. To illustrate the point, I’d like to do a little exercise.
- #16 I’d like you to estimate the weight, in pounds, of the heaviest blue whale ever recorded. No cheating, don’t Google it. Give a high and a low estimate. Here’s the catch: I want you to estimate this with a wide enough range so that you are 90% confident that the correct answer is in the range that you set. You’ve got one minute. Go.
- #17 Now, I’d like to get a show of hands of how many of you captured the correct answer in your range. Almost everyone gets this wrong.
- #18 You might be thinking, “c’mon, this is not a realistic exercise.” Folks, estimating in the face of this kind of uncertainty is business as usual for software estimators. Fortunately, there are techniques that will help you get within 25% of the actual number 75% of the time. The other takeaway here is unless you are into statistics and you have have a mathematical reason for saying so, don’t use terms like “90% confident” or “75% confident.”
- #19 Before we go any further, I’d like to share a book recommendation. The exercise we just did comes from chapter 2 of the book Software Estimation, by Steve McConnell. Steve is a former Microsoft employee and also authored the book Code Complete. Software Estimation is pretty much required reading for anyone who is responsible for estimating software projects. This book really helped me to understand why good estimation practices work, and what I had been doing wrong for years before.
- #20 Hofstadter’s Law illustrates why estimation is so hard, and why so many people get it wrong. In fact, the difficulties with producing even a ballpark estimate and the the tendency to misunderstand and abuse estimation have led some to seek workflows which eliminate estimation altogether. Some agile methodologies do this. Sadly, the dynamics and business models of many companies do not allow such a luxury.
- #46 We’ve talked about a lot of theory, what estimates are, what they’re good for. Now let’s talk about some practical methodology.
- #47 Remember Rob Bowley’s timeframes?
- #48 This is the underlying idea behind estimation by decomposition. Essentially, you break down the project features, and then you break down those sub-features down even further to the individual components that must be built. Estimate each component, and sum the individual estimates to produce the overall estimate.
- #50 There are a few different ways to do this. The first way was pretty hard for me to swallow at first. I learned it from Paul Jones and in practice it works very well. This method includes front-end, back-end, and QA time built in and was created based on his personal observations from working on many different projects. Notice the large unit of measure (1 day), and the fact that it assumes two people will be pair programming. I never understood why this method worked so well until I learned about the law of large numbers. Simple methods are often quite effective! It doesn’t take complex mathematics or estimation modeling software to produce a useful estimate. A spreadsheet and a good method are all you need.
- #71 Had four separate systems in place for managing customer data, billing, inventory, and fulfillment
- #72 Did I mention we needed the money?
- #73 $25-30/hr effectively