10 Deadly Sins of

Software Estimation
Steve McConnell
2002 Construx Software Builders, Inc.
All Rights Reserved.
www.construx.com

Construx

Del
ive ring Softw are Proje ct Succe ss

Background

Estimation Book
v Construx Estimate
v Construxs Training
v Construxs Consulting
v

www.construx.com

consulting u training u software projects u construx.com

Art and Science of Software

Estimation
Science of estimation is well-developed
and well-supported by software tools
v Art of estimation relies on rules of thumb
and still needs some work
v

consulting u training u software projects u construx.com

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

consulting u training u software projects u construx.com

Sin #19

Assuming that the most reliable estimates

come from the people with the most
powerful vocal chords

consulting u training u software projects u construx.com

Sin #18

Telling someone youre writing an

estimation book, because they will say,
When do you estimate youll be done, ha
ha ha.

consulting u training u software projects u construx.com

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 projects plans on the past
projects estimated results instead of its
actual results

consulting u training u software projects u construx.com

Sin #16

Assuming that the sales department is

better at estimating software projects than
the programmers are

consulting u training u software projects u construx.com

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
- etc
10

consulting u training u software projects u construx.com

Sin #14

Presenting estimates with a high degree of

precision (67.4 days) that are supported
by only a low degree of accuracy (2
months)

11

consulting u training u software projects u construx.com

Sin #13

Believing that software estimation tools

cant possibly match the computing power
of a pencil and a beer-stained napkin

12

consulting u training u software projects u construx.com

Sin #12

Reasoning that, The sooner we fall

behind schedule, the more time well have
to catch up.

13

consulting u training u software projects u construx.com

Sin #11

Arguing that the software developers are

padding their estimates just so they can
look good
when the last time anyone delivered a
software project early was during the
Nixon administration!

14

consulting u training u software projects u construx.com

Deadly Sins

Sin #1
Confusing Targets
with Estimates

Confusing Estimates with

Targets
v
v
v

The software industry does lots of target

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

17

consulting u training u software projects u construx.com

Differentiate Between
Targets and Estimates
v

Target setting is a key part of the art of

estimation
v When youre asked to provide an estimate,
determine whether youre 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
18

consulting u training u software projects u construx.com

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)

20

consulting u training u software projects u construx.com

Schedule Negotiations

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
v

21

consulting u training u software projects u construx.com

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

The Cone of Uncertainty

Project cost
(effort and size)
4x

Most
estimates
are created
here

Project
schedule

Good
estimates
arent
possible
until here

2x

1.6x

1.25x

1.5x

1.15x

1.25x
1.0x
0.8x

1.1x
1.0x
0.9x

0.67x

0.85x

0.5x

0.8x

0.25x

0.6x

Time
23

consulting u training u software projects u construx.com

Plan to Revise Estimates

Throughout the Project
Project cost
(effort and size)

Project
schedule

4x

1.6x

2x

1.25x

1.5x

1.15x

1.25x
1.0x
0.8x

1.1x
1.0x
0.9x

0.67x

0.85x

0.5x

0.8x

0.25x

0.6x

Suitable only
as estimates

Suitable as estimates
Time
and commitments

consulting u training u software projects u construx.com

24

Sin #4
Assuming
Underestimation has
No Impact on Project
Results

Effect of Estimation Accuracy

Non-linear impact due
to planning errors,
upstream defects,
high-risk practices

Cost
Effort
Schedule

Overestimation

Underestimation

< 100%

Linear impact due to

Parkinsons Law

100%

>100%

Target as a Percentage of Nominal Estimate

26

consulting u training u software projects u construx.com

Sin #5
Estimating in the
Impossible Zone

Puzzle

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?
v

hill
e
p th
hu
p
m
30
ir ve
D
ile
1m

Ho
wf
ast
?
1m
ile
28

consulting u training u software projects u construx.com

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 whats-the-earliestdate-by-which-you-cant-prove-you-wont-befinished estimating.
Tom DeMarco (1982)
29

consulting u training u software projects u construx.com

Estimates Are Probability

Statements
Probability of
Success

What happens when you take

a nominal estimate and
compress it?
There is no such thing as a
single-point estimate that is
correct/meaningful
All estimates include at least
implied probabilities (even if
the estimator doesnt know it)

Estimated
Completion
Time

95%

12 months

75%

11 months

50%

10 months

25%

9 months

0%

8 months
7 months
6 months

consulting u training u software projects u construx.com

5 months
4 months
3 months
2 months
1 month

30

Schedule Compression and the

Impossible Zone
Price

Jensen

Putnam

1.4

Cocomo 81

1.3

Relative Effort MM/Manor

DSN

The
Impossible
Zone

1.2

1.1

1.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

1.1

1.2

1.3

0.9

0.8

Mk II FP
estimating
method

0.7

Relative Schedule (Tdesired / Tnorm )

Source: Adapted from Charles Simons, Software Sizing and Estimating: Mk II, John Wiley & Sons, 1991.

31

consulting u training u software projects u construx.com

Effort/Schedule Tradeoff

All researchers have found some tradeoff

between schedule compression and effort
v No one thinks theres no tradeoff
v Assume a maximum possible schedule
compression of about 25%
v

32

consulting u training u software projects u construx.com

Dont Create Estimates

in the Impossible Zone
v

Whats the solution to the puzzle?

hill
e
h
pt
hu
p
m
30
e
iv
Dr
ile
1m

oo
1m
ile
33

consulting u training u software projects u construx.com

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 Maximum effectiveness doesnt appear during first use
v First use tends to be error prone
v Early claims for effectiveness are often based on expert
use--sometimes by programmers or authors who
invented the tool or method!
v Payoff is less than expected when it does appear
v New tools and methods increase risk
Best assumption is productivity loss from
initial use of new tool or method
35

consulting u training u software projects u construx.com

Sin #7
Using Only One
Estimation Technique

Example of One Technique vs.

Multiple Techniques
Code Complete Length Estimate
Chapter
Preface
Welcom e
How to Read
Metaphors
Prerequisites
Typical Steps
<snip>
Tuning
Management
Character
Review of Themes

TOTAL

Expert
Judgment
Estimate
4
5
8
11
52
27

55
30
20
20

Calc'd from
Points in
Outline
4
5
8
11
52
36

41
31
23
21

250

794

751

Original
Whole-Book
Estimate
-

37

consulting u training u software projects u construx.com

Use Multiple Techniques

Difficult to be confident in estimates

created using only one method-contributes to Brooksvigorous defense
problem
v Leading organizations use multiple
techniques
v Create estimates different ways and look
for convergence or spread among the
estimates
v

38

consulting u training u software projects u construx.com

Sin #8
Not Using Estimation
Software

Estimation Software

vs

40

consulting u training u software projects u construx.com

Use Estimation Software

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/

41

consulting u training u software projects u construx.com

Sin #9
Not Including Risk
Impacts in Estimates

How Much Risk Gets Included

in the Project Plan?
Probability

Impact

Exposure
(RE)

New technology doesnt live up

to expectations

25%

8 weeks

2.0 weeks

New technology requires staff

training

50%

1 week

0.5 weeks

Demo version of software is

required to support trade show

75%

2 weeks

1.5 weeks

Senior staff not available as

planned

25%

10 weeks

2.5 weeks

Government regulations change

before software ships

10%

2 weeks

0.2 weeks

23 weeks

6.7 weeks

Risk

Total

43

consulting u training u software projects u construx.com

Addressing Risk
in Estimates
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
v

44

consulting u training u software projects u construx.com

Sin #10
Providing Off-The-Cuff
Estimates

Treat Estimation as a
Mini-Project
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)

46

consulting u training u software projects u construx.com

Define a Standardized
Estimation Procedure
Elements of a standardized procedure:
v A clear description of an estimates
imprecision
v Use of multiple estimation approaches
v A plan to re-estimate at pre-defined points
in the project
v Definition of when estimates become
commitments
47

consulting u training u software projects u construx.com

Decompose Big Estimates

Into Smaller Estimates
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
v

48

consulting u training u software projects u construx.com

Conclusions

Bad estimates (or targets) are the norm

v Good estimates are possible!
v Deadly sins and rules of thumb presented
here are just the tip of the iceberg
v

49

consulting u training u software projects u construx.com

Summary of 10 Deadly Sins

v
v
v

Confusing targets with

estimates
Saying yes when you
really mean no
Committing to estimates
too early in the cone of
uncertainty
Assuming underestimation
has no impact on project
results
Estimating in the
impossible zone

v
v
v
v
v

Overestimating savings
from new tools or methods
Using only one estimation
technique
Not using estimation
software
Not including risk impacts
in estimates
Providing off-the-cuff
estimates

50

consulting u training u software projects u construx.com

Construx

Del
ive ring Softw are Proje ct Succe ss

Services

Software Resources

vSoftware Projects
vConsulting
vSeminars

vinfo@construx.com
vwww.construx.com

In-Depth Estimation Workshop:

www.construx.com/seminars/