Page 42 -

M 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 tasks will be very large (“Test
the guidance system”); for small projects (like writing a simple calculator program), the
tasks are small (“Build the arithmetic object that adds, multiplies, or divides two num-
bers”). The team must take care in generating the WBS—if the tasks are incorrect, they
can waste time going down a wrong path.
Once the WBS is created, the team must create an estimate of the effort required to per-
form each task. The most accurate estimates are those that rely on prior experience. Team
members should review previous project results and find how long similar tasks in previ-

ous projects took to complete. Sources of delays in the past should be taken into account
when making current estimates. Postmortem reports (see Chapter 8) are a good source of
this information.

No estimate is guaranteed to be accurate. People get sick or leave the organization; teams
run into unforeseen technical problems; the needs of the organization change. The unex-
pected will almost certainly happen. Therefore, the goal of estimation is not to predict the
future. Instead, it is to gauge an honest, well-informed opinion of the effort required to do a
task from those people in the organization who have the most applicable training and
knowledge.

34 CHAPTER THREE