The Cone Doesn t Narrow Itself

The Cone Doesn't Narrow Itself

Another way in which the Cone of Uncertainty represents a best-case estimate is that if the project is not well controlled, or if the estimators aren't very skilled, estimates can fail to improve. Figure 4-3 shows what happens when the project doesn't focus on reducing variability—the uncertainty isn't a Cone, but rather a Cloud that persists to the end of the project. The issue isn't really that the estimates don't converge; the issue is that the project itself doesn't converge—that is, it doesn't drive out enough variability to support more accurate estimates.

Figure 4-3: If a project is not well controlled or well estimated, you can end up with a Cloud of Uncertainty that contains even more estimation error than that represented by the Cone.

The Cone narrows only as you make decisions that eliminate variability. As Figure 4-4 illustrates, defining the product vision (including committing to what you will not do) reduces variability. Defining requirements—again, including what you are not going to do—eliminates variability further. Designing the user interface helps to reduce the risk of variability arising from misunderstood requirements. Of course, if the product isn't really defined, or if the product definition gets redefined later, the Cone will widen, and estimation accuracy will be poorer.

Figure 4-4: The Cone of Uncertainty doesn't narrow itself. You narrow the Cone by making decisions that remove sources of variability from the project. Some of these decisions are about what the project will deliver; some are about what the project will not deliver. If these decisions change later, the Cone will widen.

Tip #12 

Don't assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow by removing sources of variability from your project.

Accounting for the Cone of Uncertainty in Software Estimates

Studies of software estimates have found that estimators who start with single-point estimates and create ranges based on their original single-point numbers do not usually adjust their minimum and maximum values sufficiently to account for the uncertainty in the estimate, especially in circumstances that contain high uncertainty (Jørgensen 2002). This tendency to use ranges that are too narrow can be addressed two ways. The first is to start with a "most likely" estimate and then compute the ranges using predefined multipliers, as shown in Table 4-1.

Table 4-1: Estimation Error by Software-Development Activity

		Scoping Error
Phase	Possible Error on Low Side	Possible Error on High Side	Range of High to Low Estimates
Initial Concept	0.25x (-75%)	4.0x (+300%)	16x
Approved Product Definition	0.50x (-50%)	2.0x (+100%)	4x
Requirements Complete	0.67x (-33%)	1.5x (+50%)	2.25x
User Interface Design Complete	0.80x (-20%)	1.25x (+25%)	1.6x
Detailed Design Complete (for sequential projects)	0.90x (-10%)	1.10x (+10%)	1.2x
Source: Adapted from Software Estimation with Cocomo II (Boehm et al. 2000).

If you use the entries from this table, recognize that at the point when you create the estimate you won't know whether the actual project outcome will fall toward the high end or the low end of your range.

Tip #13 

Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.

A second approach is based on the finding that estimation "know-how-much" and estimation "know-how-uncertain" are two different skills. You can have one person estimate the best-case and worst-case ends of the range and a second person estimate the likelihood that the actual result will fall within that range (Jørgensen 2002).

Tip #14 

Account for the Cone of Uncertainty by having one person create the "how much" part of the estimate and a different person create the "how uncertain" part of the estimate.

Relationship Between the Cone of Uncertainty and Commitment

Software organizations routinely sabotage their own projects by making commitments too early in the Cone of Uncertainty. If you commit at Initial Concept or Product Definition time, you will have a factor of 2x to 4x error in your estimates. As discussed in Chapter 1, "What Is an 'Estimate'?", a skilled project manager can navigate a project to completion if the estimate is within about 20% of the project reality. But no manager can navigate a project to a successful conclusion when the estimates are off by several hundred percent.

Meaningful commitments are not possible in the early, wide part of the Cone. Effective organizations delay their commitments until they have done the work to force the Cone to narrow. Meaningful commitments in the early-middle part of the project (about 30% of the way in) are possible and appropriate.

The Cone of Uncertainty and Iterative Development

Applying the Cone of Uncertainty to iterative projects is somewhat more involved than applying it to sequential projects is.

If you're working on a project that does a full development cycle each iteration—that is, from requirements definition through release—you'll go through a miniature Cone on each iteration. Before you do the requirements work for the iteration, you'll be at the Approved Product Definition point in the Cone, subject to 4x variability from high to low estimates. With short iterations (less than a month), you can move from Approved Product Definition to Requirements Complete and User Interface Design Complete in a few days, reducing your variability from 4x to 1.6x. If your schedule is immovable, the 1.6x variability will apply to the specific features you can deliver in the time available, rather than to the effort or schedule. There are estimation advantages that flow from short iterations, which are discussed in Section 8.4, "Using Data from Your Current Project."

What you give up with approaches that leave requirements undefined until the beginning of each iteration is long-range predictability about the combination of cost, schedule, and features you'll deliver several iterations down the road. As Chapter 3, "Value of Accurate Estimates," discussed, your business might prioritize that flexibility highly, or it might prefer that your projects provide more predictability.

The alternative to total iteration is not no iteration. That option has been found to be almost universally ineffective. The alternatives are less iteration or different iteration.

Many development teams settle on a middle ground in which a majority of requirements are defined at the front end of the project, but design, construction, test, and release are performed in short iterations. In other words, the project moves sequentially through the User Interface Design Complete milestone (about 30% of the calendar time into the project) and then shifts to a more iterative approach from that point forward. This drives down the variability arising from the Cone to about ±25%, which allows for project control that is good enough to hit a target while still tapping into major benefits of iterative development. Project teams can leave some amount of planned time for as-yet-to-be-determined requirements at the end of the project. That introduces a little bit of variability related to the feature set, which in this case is positive variability because you'll exercise it only if you identify desirable features to implement. This middle ground supports long-range predictability of cost and schedule as well as a moderate amount of requirements flexibility.