Cone of Uncertainty Explained with Examples

Editorial Team

Cone of Uncertainty

The cone of uncertainty entails the uncertainty and risks when an organization invests in a software project. The cone depicts the number of risks and degree of precision for uncertainty through the funnel. The further an organization tries to forecast features, capabilities, and adoption, the more risk and uncertainty it must assume.

An organization must have uncertainty when defining a product to deliver and the timing to deliver it to the market. This article covers the basics of the cone of uncertainties, gives an example of the uncertainty, and offers solutions to the uncertainties.

What is Cone of Uncertainty?

The cone of uncertainty is a term often used in project management, to describe the phenomenon by which, project unknowns decrease with time. At the start of a project, comparatively little is known about the product or work results. So estimates are subject to uncertainty.

As a team conducts more research and development, they learn more about the project. The uncertainty tends to decrease, reaching 0% when the team terminates and transfers all the residual risks. The processes usually happen at the end of a project, i.e., transferring the responsibility to a separate maintenance group.

Project unknowns or uncertainty largely correlate to variance in project estimates. The term cone of uncertainty applies in software development, where the business and technical environments change very fast. The majority of the environments change so slowly that they can be thought of as static for a typical project’s duration. Therefore, traditional project management methods focus on achieving a full understanding of the environment through careful analysis and planning.

The American Association of Cost Engineering created the cone of uncertainty to assist in estimations for engineering and construction. The tool is applied to various phenomena such as a hurricane. For example, the system’s course is less certain when predicted further into the future, and more certain as time goes on and the system gets closer.

Before an organization makes any significant investments, it reduces the cone uncertainty to a level where they can comfortably handle the risks. In this environment, the uncertainty level reduces rapidly in the beginning, and the cone shape is obvious. However, the software business is very volatile, and there is external pressure to reduce the uncertainty level as time goes by. 

Research and decisions which remove the source of variability from a project narrow the cone of uncertainty. These decisions are about the scope, what is included and not included in the project. If these decisions change later, then the cone will widen.

Cone of Uncertainty in Agile and Scrum

Cone of uncertainty in the Product Backlog is a big risk for the schedule of a scrum project. Product Backlog is a prioritized list of work for the development team, derived from the roadmap and its requirements. The problem is that the full scope of the release can be quite hard to estimate since the requirements aren’t well known. Confounding this problem is difficult since the release date is a hard deadline. Thus an agile team must perform an unknown about work in a fixed amount of time.

The software development schedule aligns to address, the highest priority feature sets, and features in early iterations in anticipation of scope problems. Additionally, it defers lower priority sets and features to later iterations. Reduce the cone of uncertainty and the risks around missing a release deadline. Then further, the requirements lead (product owner).

The scrum team must actively defer low priority features from all feature sets to later sprints. Hence an organization escapes the case of being unable to release a minimally acceptable product. Since time spent on low priority features from high priority feature, sets when it could have been spent on all individually high priority features across feature sets.

Agile helps develop the estimate and also forces the team to estimate as they learn more constantly. As the team learns more about a product and the market, it gets easier for them to estimate the uncertainties. Agile and the cone of uncertainty are a powerful combination. Since Agile helps empower teams to deliver an outcome. However, it isn’t the answer to all the team’s questions.

The agile approach accelerates a team’s ability to learn with constant iterations. It also enables the team to validate the learnings more quickly and learn more about the market. Which can reduce the cone of uncertainties.

Applying agile and scrum properly helps organizations address the cone and reduce uncertainty. Empowering software development teams to deliver business value.

Cone of Uncertainty – How to Deal with it?

The cone of uncertainty represents the evolution of the amount of best-case uncertainty during a project. Predicting the success of a project is extremely difficult. Many factors can influence a company’s estimate and contribute to project uncertainties.

While developing an estimate, it’s good for an organization to base its estimate on a similar project. The following ways have proven to be effective in dealing with the cone of uncertainty:

  • Buffering (margin of error)

Buffering involves the use of a percentage of time or resources to cushion the effect of materializing risks. Giving too large numbers causes sponsors or clients to resist and disapprove a project. Again too low numbers make an organization run out of time and money.

The situation becomes doubly risky when an organization uses fixed contracts for their proposal, where there is even more pressure to keep the cost down.

A crucial step for an organization to take is, to use their historical data to compare their current project with other complicated projects. Therefore, obtain reasonable and justifiable numbers to get a margin of error or buffering. They can also include the lessons they learned at the end of each project to support their buffering figures in the future.

  • Estimates in ranges

Agile approaches for project management ensure honesty from the beginning of a project and never uses closed figures. An organization should always be transparent and use ranges, especially in projects that seek to innovate, and try new things where there is a lot of cone of uncertainty.

Additionally, an organization should present the best estimates at the moment as a range. The estimates help sponsors to decide how much risk they are willing to accept.

  • Relative estimation

The agile approach uses interesting concepts like story points and ideal days to make relative estimates. A story point is a metric used in agile project management, and development. To estimate the difficulty of implementing a given user story, and an abstract measure of efforts required to implement it. It’s a number that tells the team about the difficulty level of a story.

Ideal days entail the number of days of efforts that it would take, the team to get a story done if the team works with no interruptions. Once the team sizes the baseline story, it’s ready to compare other stories and assign points to them.

The use of ideal days and story point helps a team estimate the cone of uncertainty and put in place measures to reduce them.

  • Fund incrementally

With incremental funding, an organization doesn’t ask for the whole bag of money upfront. It only takes enough to spike through enough of the work to report back a better number on how long it will take. The use of half of the money helps an organization see how long the amount takes the project and can go a long way in reducing the variance in that upfront number. Hence reduce the cone of uncertainty.

Cone of Uncertainty Examples

The cone of uncertainty is not the results of a project’s past performance. The cone is the planned boundaries (upper and lower limits) of the needed reduction in uncertainty regarding the project as it proceeds.

When the actual cost, schedule, and technical performance are outside the planned cone of uncertainty. The team takes corrective actions to move uncertainties inside the cone, if the project meets its cost, schedule, and technical performance goals.

An example of a cone of uncertainty is where an engineering team is designing an oven’s temperature. The engineering team defines the UCL and LCL before the start of the project. These inform the designer of the progress of the project as it proceeds. Their goal is to stay inside the temperature limit until they finish the project.

Another example is the weight reduction attribute with an error band. In this example, the team has to reduce the weight as the program proceeds left to right. Their target weight is at a test readiness review of 23KG. A 25 KG vehicle is sold in the proposal, and the target weight margin is 23KG.

As the program proceeds, there are UCL and LCL bands that follow the planned weight. During the process, each of the models’ weight measurements, through to a final article is compared to the planned weight. Therefore, they keep the value (25KG) inside the error band of the needed weight reduction to stay on plan and reduce the cone of uncertainty.


The use of the cone of uncertainty is important as it allows an organization, to analyze trends that help focus on problematic areas at the earliest point in time. It provides early insight into error-prone products. That the team can correct earlier and thereby lower cost. Additionally, the cone of uncertainty helps avoid or minimize cost overruns and schedule slips by detecting them earlier. It also helps perform better technical planning and adjust resources based on discrepancies between planned and actual progress.