The Cone of Uncertainty

And how to avoid it turning into a wormhole

The Cone of Uncertainty is a phenomenon known for some time, but it only started to become accepted in software development during the past decade, primarily because of the rise of agile methodologies.

Definition

In project management, the cone of uncertainty describes the graph that gives estimate variability over time. The level of accuracy of a given estimate increases over time (the variability decreases), when you work towards the end of the project. This might seem obvious, but it’s often ignored by business owners and managers who demand an accurate estimate even before the project started. The ‘Theory of the Cone’ shows that you can NEVER provide an accurate estimate, but should rather provide a range. This range can be used as an aid (but not the only one!) for planning and budgeting purposes.

This means that you can only give accurate estimates when you’re nearing the end of the project. In the beginning of the project, when the scope isn’t yet well defined and some, or even most, of the requirements are still a bit ambiguous, you’re better off with providing a range.

The following graphs shows the cone in all of its glory:

This graphs shows that any estimate given at the time of the initial concept might be 4x off, positive or negative. A concept estimated to take 6 months, might therefore take any time between 2 years and 2 months…

At the point where all the requirements are known (and assuming that they won’t change, so this is clearly a theoretical exercise for now…) this estimate might turn out to become anything between 9 and 4 months.

When the detailed design is ready, the same estimate will be within the range of 7,5 and 4,8 months (between 1.25x and 0.8x, where x=6 (months)).

How to use the cone in your advantage as an agile project manager?

In order to cope with “the reality of the cone”, you should convince the project’s stakeholders that it’s better to spend some money at the beginning of the project, so that the estimate given later on will have a smaller range of variability.

In other words: spend 3-4 iterations and review the estimate so that the range of variability becomes smaller. In a proper agile approach, the high risk items will be covered during the first iterations anyway.

Sunny Day vs. Rainy Day

In order to provide both sunny and rainy day estimates at any given time during the project, you can just use the maximum and minimum of the cone, depending on where you are in your project schedule.

In the beginning of the project, the sunny day and rainy day scenario’s can be months apart from each other. Nearing the end, the difference can be a matter of days (depending on overall project size).

Risk, buffering and padding

The cone doesn’t take all risk into account. Don’t rely on the cone as the only way to visualize risk!

The Wormhole of Uncertainty

The ‘Wormhole of Uncertainty’ looks like this:

As you can see, this graph starts as a cone, but never converges. The reason for this is that last minute bugs are found, and keep on being found, resulting in the estimate to remain unclear, and with a high degree of variability. If this situation is not turned around, the project will either go on forever, or will end with too many remaining bugs in the final release.

How to prevent the Wormhole ?

The wormhole can be prevented by following the tips below:

• Test-driven development will help to write good unit tests early in the process
• Automated testing will improve the results of user level testing and regression testing
• Frequent code check-ins combined with proper continuous integration will keep your code base stable and bug-free
• Customer engagement throughout the process will make sure that the focus of the development efforts remains aligned with customer vision
• Deploy early releases as often and as early possible in front of the customers

All of these recommendations have AGILE written all over them.

The nature of a traditional ‘waterfall’ project results in a higher risk for a cone that doesn’t converge. The risks of too many bugs, or unexpected requirement changes at the end of the project are just too high.

This is one of the explanations why traditional project approaches have a much higher failure rate than the agile ones.

Stefan Luyten

For more information: http://www.triton-consulting.be