1 / 27 CS 709B Advanced Software Project Management and Development Software Estimation - I Based on Chapters 1-3 of the book [McConnell 2006] Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006 April 24, 2012

2 / 27 Outline n n Critical Estimation Concepts u u What is an “Estimate”? [Chapter 1] u u How Good an Estimator Are You? [Chapter 2] u u Value of Accurate Estimates [Chapter 3]

3 / 27 What is an “Estimate”? n n Estimates, targets, commitments: 3 different things! n n Estimate – dictionary definitions: (1) A tentative evaluation or rough calculation (2) A preliminary calculation of a project’s cost (3) A judgment based upon one’s impressions n n Target: a statement of a desirable business objective n n Commitment: a promise to deliver defined functionality at a specific level of quality by a certain date

4 / 27 What is an “Estimate”? n n Relationship between estimates and plans: u u Related, but different topics u u Estimation is an unbiased, analytical process u u Planning is a biased, goal seeking-process u u Estimates form the foundation for plans u u Planning activities that depend on estimates: ● ●Creating a detailed schedule ● ●Identifying the project’s critical path ● ●Creating a complete work breakdown structure ● ●Prioritizing functionality for delivery ● ●Breaking a project into iterations

5 / 27 What is an “Estimate”? n n Key estimation question: what are the odds to complete the project on time and within budget? n Meaningless single-point estimate:

6 / 27 What is an “Estimate”? n n A single-point estimate is usually a target masquerading as an estimate n Probabilities need to be considered

7 / 27 What is an “Estimate”? n More realistic distribution of probabilities in software estimation

8 / 27 What is an “Estimate”? n Probability of delivering a project on or before a specific date

9 / 27 What is an “Estimate”? n When you see a single point estimate, that number’s probability is not 100%. Ask what the probability of that number is.

10 / 27 What is an “Estimate”? n Express an estimate as: u “Percent confident” (e.g., 90% confident in a 24-week schedule) u Best case and worst case u Range (“we are estimating 18 to 24 weeks”) n What is a good estimate? u Capers Jones (1998): +/- 10% accuracy is possible, but only on well controlled projects u Conte et al (1986): a good estimation approach will be within 25% of actual results 75% of the time [most common standard to evaluate estimation accuracy (Stutzke 2005)]

11 / 27 What is an “Estimate”? n Results vs. estimates in a set of US Air Force projects

12 / 27 What is an “Estimate”? n Improvement program at Boeing

13 / 27 What is an “Estimate”? n Improved estimations at Schlumberger

14 / 27 What is an “Estimate”? n Notably, accurate estimations cannot be achieved through estimation practices alone. They also need effective project control [see note on Heisenberg’s Principle of Uncertainty]

15 / 27 What is an “Estimate”? n Project control activities (related to change) include: u Removing non-critical requirements u Redefining requirements u Replacing less-experienced staff with more-experienced personnel n In practice, if the project is delivered with about the level of functionality intended, using approximately the same level of resources as planned, in about the time frame targeted, then we can say that the “project met its estimate” n An estimate is good not only in terms of its intrinsic predictive capability but also in terms of supporting the project’s success

16 / 27 What is an “Estimate”? n n Estimates don’t need to be perfectly accurate as much as they need to be useful n n A 20% gap (or less) between estimate and target is manageable n n A larger gap needs reconsidering the project’s target n n The real purpose of an estimation is to determine whether a project’s targets are realistic enough to allow the project to be controlled by them n n Steve McConnell working definition of a good estimation: 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 its targets

17 / 27 How Good an Estimator Are You? n n Quiz [10 minutes]: For each question, fill in the upper and lower bounds that, in your opinion, give you 90% chance of including the correct value. Be careful not to make your ranges either too wide or too narrow. Make them wide enough so that, in your best judgement, the ranges give you a 90% chance of including the correct answer. Do not research your answers.

18 / 27 How Good an Estimator Are You? nn nn

19 / 27 How Good an Estimator Are You? n n Results (most recent 600 quiz takers)

20 / 27 How Good an Estimator Are You? n n Discussion: u u Specific percentages such as “90%” are meaningless unless supported by some statistical analysis u u Don’t provide “percentage confident” estimates (especially “90% confident”) unless you have a quantitatively-derived basis for doing so u u Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates do not artificially misrepresent your confidence in estimates u u If you are feeling pressure to make your ranges narrower make sure the pressure is not self-induced

21 / 27 Value of Accurate Estimates n n Is it better to overestimate or underestimate? n n Arguments against overestimation: u u Parkinson’s Law: the work will expand to fill available time u u Goldratt’s Student Syndrome: developers will procrastinate until late in the project, and then they’ll rush when it will be likely too late to complete the project on time u u Underestimation will instill a sense of urgency in the team n n Arguments against underestimation u u Reduced effectiveness of project plans u u Statistically reduced chance of on-time completion u u Poor technical foundations >> worse-than-nominal results u u Destructive late project dynamics: more status meetings, re- estimations, interim releases, apologizing to key customers, etc.

22 / 27 Value of Accurate Estimates n n Don’t intentionally underestimate. Address concerns of overestimation through planning and control, not through biasing your estimation.

23 / 27 Value of Accurate Estimates n n The reality in the software industry

24 / 27 Value of Accurate Estimates n n The reality in the software industry (continued): [Capers Jones, 1998]

25 / 27 Value of Accurate Estimates n n The reality in the software industry (continued)

26 / 27 Value of Accurate Estimates n n The software industry’s systemic problem: underestimation! n n Benefits of accurate estimates u u Improved status visibility u u Higher quality u u Better coordination with non-software functions u u Better budgeting u u Increased credibility u u Early risk information

27 / 27 Value of Accurate Estimates n n Predictability vs. flexibility/time/cost/functionality