Managing Expectations During Software Effort Estimation

Estimation is one of the most personally hazardous activities software developers engage in. As professionals, we have an obligation to commit only to things we know we can achieve.

Speaker Ryan Findley, Owner and Founder of Neomind Labs, will provide the tools necessary to clearly distinguish between an estimate and a commitment, and to educate your customers about the appropriate uses of each.

He will also address the use of cost accounting in software project management, and what it means to have high throughput.

Transcript

1. Managing Expectations During Software Effort Estimation 1 1
2. Hello World Neomind Labs is a custom software consultancy based here in Center City Philadelphia. 2 2
3. "Estimation is one of the simplest, yet most frightening activities that software professionals face. So much business value depends on it. So much of our reputations ride on it. So much of our angst and failure are caused by it. It is the primary wedge that has been driven between business people and developers. It is the source of nearly all the distrust that rules that relationship". -- Robert Martin 3 3
4. Define “it” The requirements are the contract between the customer and the developers What does it look like? What does it do? what does it not do? 4 4
5. Decide how we will build “it” Plan of action INVEST in good stories and SMART tasks 5 5
6. Estimate effort What is the unit of estimation? How will you estimate? Wideband Delphi AKA "flying fingers", "planning poker" Affinity Estimation (arrange things from "fast" to "slow") Trivariate Analysis (choose optimistic, pessimistic and nominal estimates, then do math to find expected duration and standard deviations) 6 6
7. What is this thing we’ve made? "Businesses like to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound" -- Robert Martin 7 7
8. It’s a Guess It’s not enough to simply add up all of the components: Interdependencies Known unknowns Unknown unknowns “Risk tolerance” - will unexpected change be disruptive? 8 8
9. Be explicit, don’t imply Always be clear about what’s a guess and what’s a commitment What does it mean to “try”? You’ve likely just committed to a deadline. 9 9
10. They’re not doing it on purpose 10 10
11. Consider describing a probability distribution 11 11
12. Why did we commission an estimate? So we can... generate a ship date for marketing/PR reason choose a vendor know the cost 12 12
13. Another way of looking at it Cost is only half of the picture. What about value? 13 13
14. Two very different types of projects Project A will eventually cost about a million dollars and produce value of around $1.1 million. Project B will eventually cost about a million dollars and produce value of more than $50 million. 14 14
15. The two values of software Features “Softness” 15 15
16. Cost Minimization can be expensive Potentially at odds with risk tolerance At odds with change tolerance (discourages refactoring & investment in quality) 16 16
17. Throughput Accounting Inputs are feature requests Outputs are Running Tested Features in Use (RTFUs) Inventory is any work in the system that is not yet output (liability, not asset) Operating Expenses are costs of converting inputs to outputs 17 17
18. What about the cost? Full-time employees Operating expenses are known/fixed, decide what to build based on opportunity cost Contractors Put the project in “maintenance mode” when the marginal utility of the next RTFU is lower than the overhead 18 18
19. The short version Decide why you’re estimating before you estimate, and do the minimum to satisfy that goal (try to avoid BDUF). Have a time/money/developer budget in mind already? Try working backward from that. You probably shouldn’t build it unless the (roughly) projected cost is less than 1/4 the projected value. 19 19
20. Selling it The only way to go fast is to go well. Estimation isn’t free. The beginning of a project is when we know less than we’ll ever know again. Good architecture maximizes the number of decisions not made and allows decisions to be deferred. 20 20
21. More Reading Software Effort Estimation Considered Harmful, Matt Rogish The Clean Coder Chapter 10: Estimation, Robert "Uncle Bob" Martin The Economics of Software Design, J.B. Rainsberger Estimation is Evil, Ron Jeffries The Theory of Constraints: Throughput Accounting vs. Traditional Accounting, Jerome Rowley Thanks to Jason Garber of Prompt Works for brainstorming ideas! 21 21
22. Thanks! Ryan Findley ryan@neomindlabs.com @neomindryan, @neomindlabs Neomind Labs 22 22