Page 57 -

the estimate for each task. Additional information on PROBE can be found in A Discipline
for Software Engineering by Watts Humphrey (Addison Wesley, 1994).

COCOMO II
The Constructive Cost Model (COCOMO) is a software cost and schedule estimating
method developed by Barry Boehm in the early 1980s. Boehm developed COCOMO
empirically by running a study of 63 software development projects and statistically ana-
lyzing their results. COCOMO II was developed in the 1990s as an updated version for
modern development life cycles, and it is based on a broader set of data. The COCOMO
calculation incorporates 15 cost drivers, variables that must be provided as input for a
model that is based on the results of those studied projects. These variables cover software,
computer, personnel, and project attributes. The output of the model is a set of size and
effort estimates that can be developed into a project schedule. Additional information on
COCOMO can be found in Software Cost Estimation with Cocomo II by Barry Boehm et al.
(Prentice Hall PTR, 2000).

The Planning Game
The Planning Game is the software project planning method from Extreme Programming
(XP), a lightweight development methodology developed by Kent Beck in the 1990s at
Chrysler. It is a method used to manage the negotiation between the engineering team
(“Development”) and the stakeholders (“Business”). It gains some emotional distance
from the planning process by treating it as a game, where the playing pieces are “user sto-
ries” written on index cards and the goal is to assign value to stories and put them into
production over time.
Unlike Delphi, PROBE, and COCOMO, the Planning Game does not require a documented
description of the scope of the project to be estimated. Rather, it is a full planning process
that combines estimation with identifying the scope of the project and the tasks required
to complete the software.

Like much of XP, the planning process is highly iterative. The scope is established by having
Development and Business work together to interactively write the stories. Then, each story
is given an estimate of 1, 2, or 3 weeks. Stories that are larger than that are split up into mul-

tiple iterations. (Often, an organization will standardize on a regular story and iteration
duration: for example, day-length stories and one- or two-week iterations.) Business is
given an opportunity to steer the project between iterations. The estimates themselves are
created by the programmers, based on the stories that are created. Finally, commitments are
agreed upon. This is repeated until the next iteration of the project is planned.

Additional information on the Planning Game can be found in Extreme Programming
Explained by Kent Beck (Addison Wesley, 2000).

Diagnosing Estimation Problems

Estimation problems almost always boil down to estimates that are either too high or too low.
Padded estimates, where the team intentionally overestimates in order to give themselves

ESTIMATION 49