Published on January 29, 2014
… a summary, some tips & tricks to remember, after reading a book called… PART 1 of 2
PART 1 of 2 What is an Estimate? What is a Good Estimate? Estimation Accuracy PART 2 of 2 Estimation Techniques How to Present Estimates How to Debate & Negotiate based on Estimates
“The process is called estimation, not exactimation.” (Phillip Armour)
Dictionary definition? 1. Tentative evaluation or rough calculation 2. Preliminary calculation of the cost of a project Source: American Heritage Dictionary, 1985 …TENTATIVE …PRELIMINARY
Estimate – a prediction – how long a project will take / cost Target – a statement – desirable business objective Commitment – a promise – deliver a feature by a certain date
Estimates are not Targets Estimates are not Commitments
Estimation – an unbiased, analytical process – goal is accuracy (not seeking a particular result) Planning – a biased, goal-seeking process – goal is a particular result (specific means to a specific end)
Planning is not Estimation Estimation is not Planning Plans rely on estimates. Estimates higher than targets – plan has higher risk level.
When asked for an estimate, determine if you’re actually supposed to: - estimate - make a commitment - figure out a plan on how to hit a target
“There’s no point in being exact about something if you don’t even know what you’re talking about.” (John von Neumann)
Single-Point Estimates (e.g. 18 weeks) useless – no probability degree more likely a target masquerading as an estimate (or an estimate stripped of probability info) Accurate Estimate probability factor attached 18 weeks with 10% chances of success 18 to 24 weeks For single-point estimates, probability is not 100%. Always ask what the probability is.
Project success – good project control Criteria for a good estimate – ability to support project success, through project control Working definition of a good estimate: 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
18 weeks 18 to 19 weeks 18 to 24 weeks Avoid using artificially narrow ranges The ranges in your estimates must represent your confidence in your estimates Pressure to make ranges narrower? Verify that the pressure is actually coming from an external source – not from yourself
Arguments against over-estimation Parkinson’s Law Student Syndrome Positive stress Arguments against under-estimation Reduced effectiveness of project plans Statistically reduced chance of on-time completion Poor technical foundation Destructive late-project dynamics DON’T INTENTIONALLY UNDERESTIMATE! The penalty for underestimation is almost always more severe than the penalty for overestimation.
Improved project status visibility Higher quality Better coordination with nonsoftware functions Increased credibility for the dev team Early risk information A mismatch between business targets and estimates: early and valuable risk information that the project might not be successful. Take corrective action early, when it can do some good.
Inaccurate information about the project / team Trying to estimate a moving target Estimates – more accurate as project progresses. More refined software definition = more accurate estimate Early in the project, estimates can be off to up to 4x In the first 30% of the project estimation accuracy improves rapidly – from ±4x to ±1.25x
Consider the effect of the „Cone of Uncertainty” on the accuracy of your estimate –YOU CANNOT HAVE MORE ACCURACY THAN IS POSSIBLE at current position. Use predefined uncertainty ranges in your estimates. Do not assume the cone will narrow itself. Force the cone to narrow by removing sources of variability.
Requirements Changes NASA – 40% time for requirements changes -- USE PROJECT CONTROL STRATEGIES TO DEAL WITH UNSTABLE REQUIREMENTS Forgetting to Include Necessary Tasks Non-functional requirements, additional activities, overhead -- INCLUDE TIME FOR STATED, IMPLIED AND NON-FUNCTIONAL REQUIREMENTS (THAT IS ALL REQUIREMENTS) -- INCLUDE ALL SOFTWARE DEVELOPMENT ACTIVITIES (NOT JUST CODING AND TESTING)
Unfounded Optimism Developer estimates – statistically 20-30% off DON'T REDUCE DEVELOPER ESTIMATES – THEY'RE PROBABLY TOO OPTIMISTIC ALREADY Subjectivity and Bias „Intuition” and „quessing”, off-the-cuff estimates DON’T GIVE OFF-THE-CUFF (IMPROMPTU) ESTIMATES. EVEN A 15 MINUTE ESTIMATE IS MORE ACCURATE Accuracy versus Precision 354.5 days versus 1 year MATCH THE NUMBER OF SIGNIFICANT DIGITS IN YOUR ESTIMATE (ITS PRECISION) TO YOUR ESTIMATE’S ACCURACY
End of PART 1 of 2 … coming soon… PART 2 of 2 Estimation Techniques How to Present Estimates How to Debate & Negotiate based on Estimates Bio: Software Estimation: Demystifying the Black Art by Steve McConnell Microsoft Press, 2006
1. … a summary, some tips & tricks to remember, after reading a book called… PART 1 of 2 ; 2 ...
Testing and Estimation - Part 1 - Duration: ... 14:03 Software Test Effort Estimation Model - Duration: 12:39. ... Part 2 - Duration: ...
In One's Own Estimation Part 2 ... Software. Office Windows Weitere Software Apps. Alle ... 1:48 0,99 € Zusätzliche ...
Software Estimation Over view for the IT professsionals.
Handbook for Software Cost Estimation Prepared ... 1.2 Scope ... interaction between these activities is iterated many times as part of doing design trade ...
Chapter 5: Software effort estimation- part 2 ... Software effort estimation© The McGraw-Hill Companies, 2009 6 ... We = 1.66 , ...
2.1 Defining Cost Estimation. ... figure 1, in a classical view of software estimation ... Software cost estimation is an important part of ...
Software development effort estimation is the process of predicting the most realistic amount of effort ... Resources on Software Estimation from Steve ...
This material is excerpted from Software Estimation: ... 1-2 A common assumption is that software ... 8 Part I Critical Estimation Concepts Figure 1-3 ...