Stop Multiplying by 4

Pratical software estimation

by Chuck Reeves | @manchuck

Why?

• Owners of the code
• Project Managers biased
  • Magne Jørgensen
  • Stein Grimstad

If you have any inkling of budget or time line, Your estimate will be biased

• Magne Jørgensen
• Stein Grimstad

“I’ll tell you how I estimate things. I sit down and figure out how long I think it would take me to do it. Then I double that time and then I push it up to the next point on the time progression scale. Were the ‘Time Progress Scale’ starts off: seconds, minuets, hours and days. So if I think something is going to take me 4 hours to do. I will double it to 8 and then I would say it would take me 8 days to get it all completely done start to finish. And I’m usually right, because there are so many impediments. If you are the only one doing it yourself your schedule can be very accurate. Once you have to involve other people, you might as well just make numbers up. You might as well say ‘I think this will take me blue days to get done’”

• Park and main
• 2 Developers
• Holidays
• Completed a day early

Requirements are the key

• It’s easy to estimate what you know
• It’s hard to estimate what you know you don’t know.
• It’s very hard to estimate things that you don’t know you don’t know.

• It’s easy to estimate what you know
• It’s hard to estimate what you know you don’t know.
• It’s very hard to estimate things that you don’t know you don’t know.

• Go to work example
• Track time for requirements

Our new contact form, will have fields for entering a valid first and last name, email, and phone number

Missed place modifiers

Missed place modifiers

• I shot an elephant in my pajamas the other day. How it got into my pajamas Ill never know
• Modifies enhance nouns

Our new contact form, will have fields for first name, last name, email, and phone number. When the form is submitted, all fields will be validated

Wordy expressions

Wordy expressions

• Extra words that do not add value but muck up the requirement

Contact form, fields for: first name, last name, email, and phone number. When submitted all fields are validated

• Name in english only?
• Email from specific domain?
• Character encoding?
• Language?
• Valid phone number?

Valid phone numbers

• (202) 456-1111
• 555-1212
• 212-867-5309
• 1-800-MATTRES
• 911
• +44 871 984 6352
• +852 2280 2898
• +91 11 2679 1234

Requirement Smells

• Fast, rapid, efficient
• valid, including but not limited too, etc, and so on
• maximize, minimize, optimize, at least, between, several
• simple, easy, quick, user-friendly
• reasonable, when necessary

• Fast, rapid, efficient
• valid, including but not limited too, etc, and so on
• maximize, minimize, optimize, at least, between, several
• simple, easy, quick, user-friendly
• reasonable, when necessary

• use a set time "5 seconds"
• describe what is valid or invalid. use comprehensive list
• be sure to include appropriate values
• describe what makes it these
• how to make this judgement

The contact form, has fields for first name, last name, email, and phone number. When the form is submitted, all fields will be validated using the following rules:

• All fields will use UTF-8 encoding
• First and Last name each will be between 3 and 100 characters long
• Email will comply with RFC 822 however will be no longer than 300 characters
• Phone number will be no longer than 25 characters and validated against the FooBarPhone REST service

• Requirements grow
• Break down into smaller parts
• Focus on Phone number

In order to estimate, you must define the parameters of what you are estimating

Tools for Estimation

Historical Data

• Count LOC / Hour
• GIT commit every hour
• Functions or Classes / Hour

Dry run / Unit test

• OH Tax service WSDL
• Dont spend more than an hour

Confidence Interval (CI)

“It is better to be roughly right than precisely wrong.”

- John Maynard Keynes

• Statistical model that represents uncertinity
• Calculated using MEAN with Variance
• No need to pad

Lets get Calibrated

User Measurement Assumptions

Calibration questions

Improve your estimates

Equivalent bet

Repetition

Pros and Cons

Absurdity Test

Equivalent bet

Repetition

Pros and Cons

Absurdity Test

Answers

Fuzzy Logic

Classify feature into size groups: Very Small, Small, Medium, Large, Very Large

Group A.K.A. Wideband Delphi

Based on the law of large numbers

Team of 10

Coordinator collects estimates

Crates an iterator form

Team votes and if fails estimate again

No Uncertainty represented

Bayes Theorem

Prioritizing

• T-Shirt Sizing
  • Development & Technology Cost
  • Business Value
• Prioritization Scale
  • Importance
  • Urgency
    Important Not Important Urgent High Priority Don't do these Not Urgent Medium Priority Low Priority

Politics

• Manager Resistance
• Remove people from the problem
• Focus on Interests not Positions
• Insist on using objective Criteria

• Doctor Example
• Focus on dollars. Focus on whats best for the business
• Consider removing features or releasing as beta with known issues
• Dont negotiate the estimate

Finial tips

• Prefer hours as that can adjusted throughout the day
• Throwing more developers might not solve the problem
• Iterate be honest

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle.

Software Estimation: Demystifying the Black Art: Demystifying the Black Art (Best Practices)

How to Measure Anything: Finding the Value of Intangibles in Business

Questions?

Thank you!

Chuck Reeves | @manchuck

Slides - https://github.com/manchuck/StopMultiplyingBy4

credits

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. - by Karl Wiegers | ISBN-13: 978-0735605350

http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=tmm_pap_title_0 - by Steve McConnell | ISBN-13: 978-0735605350

How to Measure Anything: Finding the Value of Intangibles in Business - by Douglas W. Hubbard | ISBN-13: 978-1118539279

Dev Hell Podcast - Episode 29: Snappy Answers to Stupid Questions - 1:05