ESTIMATION PROTIPS ATLANTA PHP USER GROUP SEPTEMBER 2013
A presentation at AtlantaPHP in September 2013 in Atlanta, GA, USA by Jonathon Hill
ESTIMATION PROTIPS ATLANTA PHP USER GROUP SEPTEMBER 2013
ABOUT ME • Director of Development • 5+ years of full-time web development • Learned estimation from the school of hard knocks
YOUR ANSWER?
PROTIP #1: ESTIMATES ARE NOT PROMISES
“GOOD” ESTIMATES A good estimation approach should provide estimates that are within 25% of the actual results 75% of the time. Conte, Dunsmore, and Shen (1986)
SEEKING CERTAINTY Sadly, people asking for control or visibility really want certainty. Which doesn’t exist. Dan North https://twitter.com/tastapod/status/116271851767992320
DISTINCTIONS Target: a stated desirable business objective Commitment: a promise to deliver a specific product within a timeframe
E T TA A RTGIM ET S E
DEFINITION A good estimate 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
PROTIP #2: GUTS LIE
HEAVIEST BLUE WHALE EVER RECORDED 380,000 LBS
REALISTIC?
BOOK RECOMMENDATION
HOFSTADTER’S LAW “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” Douglas Hofstadter Gödel, Escher, Bach: An Eternal Golden Braid
TIME FRAMES “With software 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
WHY ARE ESTIMATES SO HARD?
IT’LL BE DIFFERENT THIS TIME!
THE PLANNING FALLACY Students estimated their senior thesis completion time in a 1994 study: 60 55.5 50 48.6 40 30 20 33.9 27.4 Best Case Expected Case Worst Case Actual 10 0 Source: Wikipedia
E S T AT IM E T H IS !
PROTIP #3: PREMATURE ESTIMATION IS SABOTAGE
DON’T ESTIMATE 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
CONE OF UNCERTAINTY
OVERESTIMATION • Inflated prices – might lose the job • Lack of urgency – project time fills up the estimate when it could have been done faster • Procrastination
UNDERESTIMATION • • • • • • • • Inadequate planning Missed deadlines Overwork, burnout More bugs Technical debt Damage control Unplanned interim releases Meetings proliferate
PROTIP #4: BIG TEAMS ARE SLOWER THAN SMALL ONES
TIME = ESTIMATE ÷ AVAILABILITY
TEAM EFFICIENCY Developers Communication 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
PROTIP #5: BEWARE UNWARRANTED PRECISION
“533.5 hours” vs “13 days” vs “3 weeks”
PROTIP #6: COUNT ALL THE THINGS
TIME FRAMES “With software 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
DECOMPOSITION AND RECOMPOSITION 1. List all the features 2. Break the features into subfeatures 3. Break the sub-features into components 4. Estimate the components 5. Add the estimates up
LAW OF LARGE NUMBERS 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.
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
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
PROTIP #7: WHEN IN A PINCH, USE A PROXY
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
PROS • Easier • Faster
CONS • Less accurate • Requires collection and archival of project historical data on a perfeature basis
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
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
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
EXAMPLE Feature Feature A Feature B Business Value L S Dev Cost S L Feature C Feature D Feature E L M M L M L
VALUE TO COST RATIOS Business Value 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
BIZ VALUE EXAMPLE Feature Feature A Feature C Feature D Feature E Feature B Business Value L L M M S Dev Cost S L M L L Net Value 3 0 0 -2 -3
PROTIP #8: YOU CAN’T NEGOTIATE MATH
E T TA A RTGIM ET S E
PROBLEM SOLVING When the estimate and target conflict: • Negotiate features • Negotiate time • Negotiate price
ATTITUDE • Try to 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
QUESTIONS?
ONE FINAL WORD A HORROR STORY
THE SETTING • Former employer of mine • Start-up, naïve and inexperienced • Needed cash bad
THE CLIENT • Local company in Atlanta • Had four separate systems in place for managing customer data, billing, inventory, and fulfillment • Wanted this unified and streamlined into a web-based backoffice application • Wanted a customer-facing portal for online ordering and bill paying
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
THE FALLOUT • 18 months later… • 2,500 man-hours • 1,500+ Subversion commits • Lots of “unknown unknowns”, hidden complexities, and scope creep
THE MORAL • Don’t succumb to pressure to be optimistic when estimating • Use a good estimation methodology • Try not to do fixed bidding • Always have a thorough scope before starting
THANK YOU! • http://brandmovers.com • http://jonathonhill.net • @compwright
