10 Deadly Sins of Software Estimation: Construx

10 Deadly Sins of
Software Estimation
© 2002 Construx Software Builders, Inc.

All Rights Reserved.
www.construx.com
Construx
Delivering Software Project Success
Background
v Estimation Book
v Construx Estimate
v Construx’s Training
v Construx’s Consulting
consulting u training u software projects u construx.com

Art and Science of Software
Estimation
v Science is well-developed and well-

supported by software tools
v The art of estimation relies more on rules
of thumb and still needs some work
Almost-Deadly Sins of
Software Estimation
Sins #20-#11
Sin #20
Estimating how long “it” will take to build

before anyone knows what “it” is
Sin #19
Assuming that the most reliable estimates

come from the people with the most
powerful vocal chords

Sin #18
Telling someone you’re writing an

estimation book, because they will say,
“When do you estimate you’ll be done, ha
ha ha.”
Sin #17
Creating an estimate for a new project by

comparing it to a past project …
… which overran its estimates...
… and ultimately realizing that you based
the new project’s plans on the past
project’s estimated results instead of its
actual results

Sin #17(a)
Creating an estimate for a new project by

comparing it to a past project …
… which worked massive overtime ...
… and ultimately realizing that, while you
based the new project’s estimates on the
past project’s actual results this time,
by using the past project you have
calibrated massive overtime into your
estimates
9
Sin #16
Assuming that the sales department is

better at estimating software projects than
the programmers are
10

Sin #15
Creating estimates that assume that no

one will go to training ...
or attend meetings …
or be called to work on another project ...
or need to support a key customer …
or take a vacation ...
or get sick …
or …
11
Sin #14
Presenting estimates with a high degree of

precision (e.g., “67.4 days”) but that are
supported by only a low degree of
accuracy (“±2 months”)
12

Sin #13
Believing that results from commercial

estimation software are no match for a
pencil and a beer-stained napkin
13
Sin #12
Reasoning that, “The sooner we fall

behind schedule, the more time we’ll have
to catch up.”
14

Sin #11
Arguing that the software developers are

padding their estimates just so they can
look good …
… when the last time the organization
delivered a software project early was
during the Nixon administration!
15
Deadly Sins
Sin #1
Confusing Targets
with Estimates
Confusing Estimates with

Targets
v The software industry does lots of target

setting
v These targets are not created through any kind
of analysis based on the work to be performed
v In practice, little real estimation is done
18

Differentiate Between
Targets and Estimates
v Target setting is a key part of the art of

estimation
v When you’re asked to provide an estimate,
determine whether you’re really supposed to
be estimating or figuring out how to meet a
target
v This is best treated as an iterative process
that brings estimates and targets into
alignment
19
Sin #2
Saying “Yes” When
You Really Mean “No”
Why Developers Say “Yes”
It is very difficult to make a vigorous,

plausible, and job-risking defense of an
estimate that is derived by no quantitative
method, supported by little data, and
certified chiefly by the hunches of the
managers.
— Fred Brooks (1975)
21
Schedule Negotiations
v Software developers tend to be introverts

and relatively young
v Marketing and sales personnel tend to be
more extroverted and organizationally
senior to the developers they negotiate
with
22

Sin #3
Committing to
Estimates Too Early in
the Cone of
Uncertainty
The Cone of Uncertainty
Project cost Project

(effort and size) schedule
Good
4x 1.6x
estimates
aren’t
Most possible
2x 1.25x
estimates until here
are created
here 1.5x 1.15x
1.25x 1.1x
1.0x 1.0x
0.8x 0.9x
0.67x 0.85x
0.5x 0.8x
0.25x 0.6x
Time
24

Plan to Revise Estimates
Throughout the Project
Project cost Project
(effort and size) schedule
4x 1.6x
2x 1.25x
1.5x 1.15x
1.25x 1.1x
1.0x 1.0x
0.8x 0.9x
0.67x 0.85x
0.5x 0.8x
0.25x 0.6x
Time
25
Sin #4
Assuming
Underestimation has a
Neutral Impact on
Project Results
Effect of Estimation Accuracy
Non-linear impact due

to planning errors,
upstream defects,
high-risk practices Cost Linear impact due to
Effort Parkinson’s Law
Schedule
Underestimation Overestimation
< 100% 100% >100%
Target as a Percentage of Nominal Estimate
27
Sin #5
Estimating in the
“Impossible Zone”
Puzzle
v Suppose you drive 30 mph up a hill 1 mile.

v How fast do you need to drive down the
hill to average 60 mph for the entire trip?
ill
theh
p Ho
phu wf
m ast?
e 30
iv
Dr 1m
ile ile
1m
29
Variation on Sin #5
[The common definition of estimate is] ‘An

estimate is the most optimistic prediction that
has a non-zero probability of coming true’ . . .
Accepting this definition leads irrevocably

toward a method called what’s-the-earliest-
date-by-which-you-can’t-prove-you-won’t-be-
finished estimating.
— Tom DeMarco (1982)
30

Schedule Compression and the
Impossible Zone
Price Jensen Putnam
1.4
Cocomo 81
1.3
DSN
The
Relative Effort MM/Manor
1.2
“Impossible
1.1
Zone”
1.0 1.0
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.1 1.2 1.3
0.9
0.8
Mk II FP
estimating
0.7 method
Relative Schedule (Tdesired / Tnorm )
Source: Adapted from Charles Simons, Software Sizing and Estimating: Mk II , John Wiley & Sons, 1991. 31
Effort/Schedule Tradeoff
v All researchers have found some tradeoff

between schedule compression and effort
v No one thinks there’s no tradeoff
v Assume a maximum possible schedule
compression of about 25%
32

Don’t Create Estimates
in the “Impossible Zone”
v What’s the solution to the puzzle?
ill
theh
p
phu
ve 30
m oo
Dri
1m
ile ile
1m
33
Sin #6
Overestimating
Savings from New
Tools or Methods
Savings from New Tools or
Methods
Problems:
v Must pay learning curve price during first use
v New tools and methods increase risk
v Maximum effectiveness doesn’t appear during
first use
v Payoff is less than expected when it does appear
Best assumption is productivity loss from
first use of new tool or method
35
Sin #7
Using Only One
Estimation Technique
Use Multiple Techniques
v Lack of this contributes to Brooks’

“vigorous defense” problem
v Most leading organizations use multiple
techniques
v Create estimates different ways and look
for convergence or spread among the
estimates
v Personal experience
37
Sin #8
Not Using Estimation
Software
Estimation Software
vs
39
Use Estimation Software
v Best support for science of estimation is

tools
v Estimates created with tools can have
more credibility than estimates created by
manual methods
v Construx Estimate--Free Download:
www.construx.com/estimate/
40

Sin #9
Not Including Risk
Impacts in Estimates
How Much Risk Gets Included

in the Project Plan?
Exposure
Risk Probability Impact (RE)
New technology doesn’t live up 25% 8 weeks 2.0 weeks
to expectations
New technology requires staff 50% 1 week 0.5 weeks
training
Demo version of software is 75% 2 weeks 1.5 weeks
required to support trade show
Senior staff not available as 25% 10 weeks 2.5 weeks
planned
Government regulations change 10% 2 weeks 0.2 weeks
before software ships
Total - 23 weeks 6.7 weeks
42

Addressing Risk
in Estimates
v Software projects are inherently risky

v The total Risk Exposure (RE) is the
expected value of the project overrun
v The RE is where “buffer planning” starts
43
Sin #10
Providing Off-The-Cuff
Estimates
Treat Estimation as a
Mini-Project
v Use of guessing and intuition to create

estimates is correlated with cost and
schedule overruns (at the 0.05 level of
significance)
v Use of simple arithmetic formulas is
negatively correlated with overruns (at the
0.01 level of significance)
45
Define a Standardized
Estimation Procedure
Elements of a standardized procedure:

v A clear description of an estimate’s
imprecision
v Use of multiple estimation approaches
v A plan to re-estimate at pre-defined points
in the project
46

Use Historical Data
v Most common estimation technique is

comparing to past projects using personal
memory
v Use of similar past projects based on
documented facts is negatively correlated
with overruns (at the 0.05 level of
significance)
47
Decompose Big Estimates

Into Smaller Estimates
v Decompose systems into modules

v Decompose big tasks into small tasks
v Makes use of a statistical property called
“the law of large numbers”—highs and
lows tend to cancel each other out
48

Adjust Your Estimation
Approach as the Project
Progresses
v Early in the project, algorithmic, “macro”

approaches work best
v Late in the project, bottom-up, task-based
estimates work best
v Different guidelines apply to different
kinds of estimates
49
Summary of 10 Deadly Sins
v Confusing targets with v Overestimating savings

estimates from new tools or methods
v Saying “yes” when you v Using only one estimation
really mean “no” technique
v Committing to estimates
v Not using estimation
too early in the cone of
uncertainty software
v Assuming underestimation v Not including risk impacts
has a neutral impact on in estimates
project results v Providing off-the-cuff
v Estimating in the estimates
“impossible zone”
50

Construx
Delivering Software Project Success
Contact Information
Services Software Resources

v Software Projects v info@construx.com
v Consulting v www.construx.com
v Seminars

10 Deadly Sins of Software Estimation: Construx

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10 Deadly Sins of Software Estimation: Construx

Uploaded by

Copyright:

Available Formats

10 Deadly Sins of

© 2002 Construx Software Builders, Inc.

consulting u training u software projects u construx.com

v Science is well-developed and well-

consulting u training u software projects u construx.com

Estimating how long “it” will take to build

consulting u training u software projects u construx.com

Assuming that the most reliable estimates

consulting u training u software projects u construx.com

Telling someone you’re writing an

consulting u training u software projects u construx.com

Creating an estimate for a new project by

consulting u training u software projects u construx.com

Creating an estimate for a new project by

consulting u training u software projects u construx.com

Assuming that the sales department is

consulting u training u software projects u construx.com

Creating estimates that assume that no

consulting u training u software projects u construx.com

Presenting estimates with a high degree of

consulting u training u software projects u construx.com

Believing that results from commercial

consulting u training u software projects u construx.com

Reasoning that, “The sooner we fall

consulting u training u software projects u construx.com

Arguing that the software developers are

consulting u training u software projects u construx.com

Confusing Estimates with

v The software industry does lots of target

consulting u training u software projects u construx.com

v Target setting is a key part of the art of

consulting u training u software projects u construx.com

It is very difficult to make a vigorous,

consulting u training u software projects u construx.com

v Software developers tend to be introverts

consulting u training u software projects u construx.com

The Cone of Uncertainty

Project cost Project

consulting u training u software projects u construx.com

consulting u training u software projects u construx.com

Non-linear impact due

< 100% 100% >100%

Target as a Percentage of Nominal Estimate

consulting u training u software projects u construx.com

v Suppose you drive 30 mph up a hill 1 mile.

consulting u training u software projects u construx.com

[The common definition of estimate is] ‘An

Accepting this definition leads irrevocably

consulting u training u software projects u construx.com

consulting u training u software projects u construx.com

v All researchers have found some tradeoff

consulting u training u software projects u construx.com

v What’s the solution to the puzzle?

consulting u training u software projects u construx.com

consulting u training u software projects u construx.com

v Lack of this contributes to Brooks’

consulting u training u software projects u construx.com

consulting u training u software projects u construx.com

Use Estimation Software

v Best support for science of estimation is

consulting u training u software projects u construx.com

How Much Risk Gets Included

consulting u training u software projects u construx.com