Chapter 3
C H A P T E R T H R E E
Estimation
,
c
h
0
3
.
2
5
1
5
2
P
a
g
e
3
3
T
u
e
s
d
a
y
,
N
o
v
e
m
b
e
r
8
,
2
0
0
5
4
:
0
0
P
M
34
C H A P T E R T H R E E
ANY PEOPLE HAVE REFERRED TO ESTIMATION AS A “BLACK ART.” This makes some intuitive sense:
at first glance, it might seem that estimation is a highly subjective process. One person might
take a day to do a task that might only require a few hours of another’s time. As a result,
when several people are asked to estimate how long it might take to perform a task, they
will often give widely differing answers. But when the work is actually performed, it takes a
real amount of time; any estimate that did not come close to that actual time is inaccurate.
To someone who has never estimated a project in a structured way, estimation seems little
more than attempting to predict the future. This view is reinforced when off-the-cuff esti-
mates are inaccurate and projects come in late. But a good formal estimation process, one
that allows the project team to reach a consensus on the estimates, can improve the accu-
racy of those estimates, making it much more likely that projects will come in on time. A
project manager can help the team to create successful estimates for any software project
by using sound techniques and understanding what makes estimates more accurate.
Elements of a Successful Estimate
A sound estimate starts with a work breakdown structure (WBS). A WBS is a list of tasks
that, if completed, will produce the final product. The way the work is broken down dic-
tates how it will be done. There are many ways to decompose a project into tasks. The
project can be broken down by feature, by project phase (requirements tasks, design tasks,
programming tasks, QA tasks, etc.), or by some combination of the two. Ideally, the WBS
should reflect the way previous projects have been developed.
A useful rule of thumb is that any project can be broken down into between 10 and 20
tasks. For large projects (for example, a space shuttle), those