The Estimation Problem That Led Me to the CUE Method

The Product Owner reads a story to the team. A developer notices that part of the work depends on an API owned by another team. The team begins to ask questions:

• “Do we know what data the API returns?”
• “Has the integration approach been decided?”
• “Do we know when the other team will have it ready?”

The team cannot tell how much work the story involves because key parts of the solution are still unknown. With more stories waiting to be reviewed, the conversation eventually turns to the estimate. Someone suggests a story size. The team agrees and moves on.

If you’ve been part of a sprint planning session, this scenario probably sounds familiar.

When I started coaching, I watched teams work hard throughout a sprint, only to complete a fraction of what they had committed to, or worse, finish the sprint with zero story points completed. The estimates used to plan the work often did not reflect what was actually required.

This was not unique to one team. I kept seeing the same pattern across different organizations: the estimates were not giving teams the predictability they needed.

One team in particular helped me understand why. It was 2014, and I was working with a large organization facing aggressive timelines after a merger. Each company had been using a different booking system, and the team was responsible for bringing them together into one system. Work like that comes with questions nobody has answered yet.

Sprint after sprint, the team missed its commitments. Sprint Reviews often had nothing to demo because the team was not completing the stories. The unfinished work carried over while the deadline remained unchanged.

I met with the team to understand what was getting in the way. The answers came quickly. The requirements were vague. There were too many dependencies. They had lost their most senior developer. And they were learning a new technology stack while trying to deliver the work they had committed to.

I wanted to see the problem firsthand, so I sat in on their backlog refinement and sprint planning sessions. What I observed was that some stories were vague, just as the team had said, but even stories they had discussed, refined, and brought into the sprint often went unfinished.

The problem was not a lack of skill. It was a lack of information.

I started paying closer attention to how the team sized its stories. What I noticed was that their estimates were based primarily on two things: how complex the story was and how much work they thought it would take. They also increased the estimate to account for things they weren’t sure about.

That last part caught my attention. The team was already accounting for the unknowns, but those unknowns were being folded into the estimate instead of being discussed on their own. An idea came to me, and I wanted to try an experiment with the team.

The Experiment

What if, instead of increasing the estimate to account for what the team did not know, we gave uncertainty its own score?

That would make the unknowns visible instead of burying them inside a bigger estimate.

I proposed that we start scoring uncertainty separately. We agreed to use the same Fibonacci scale as the story points and considered an uncertainty score of 8 or higher to be high. When the uncertainty score reached that threshold, we created a Spike: a short, time-boxed investigation focused on answering the biggest unknowns and reducing the uncertainty.

The goal was to separate the work the team understood from the work that still required more learning. With those questions answered, the team could return to the story with greater confidence.

In Sprint Planning, we reviewed the prioritized stories, scored the uncertainty of each one, and created Spikes for those with high uncertainty.

The team committed to stories that did not carry high uncertainty, along with the new Spikes created for stories in the backlog. By the end of the sprint, the team had completed most of the stories it committed to and finished the Spikes as well.

During the Retrospective, the team said they had been more focused, dealt with fewer interruptions, and completed stories faster than in previous sprints. The sprint results reflected that. There was less unfinished work carrying over, and the completed Spikes gave the team more information about upcoming stories.

The biggest takeaway was simple: do not commit to stories that carry too much uncertainty.

In the next sprint, we went further. Uncertainty was not the only factor being folded into a single story point. Complexity and effort were different too, and we decided to consider each one separately.

Instead of sizing the story as a whole, we began scoring three factors: complexity, uncertainty, and effort.

Each story received three scores, which we averaged to create a starting point for the final estimate. We also took a quick confidence vote. The vote captured residual doubt that the three individual scores had not fully expressed. When confidence was high, we rounded the average to the nearest Fibonacci number. When confidence was lower, we rounded up to the next one.

Over the next few sprints, the results became more consistent. Sprint Reviews had working software to demo. Less work carried over. At one point, the team completed every story it had committed to and pulled additional work from the backlog.

The Spikes proved valuable too. Spending time answering open questions before committing to a story was far more useful than discovering those same unknowns during a sprint.

The biggest change, however, was in the refinement conversations. A story point was no longer the only acceptable outcome. “We do not know enough yet” became a valid reason to stop estimating and learn more first.

Estimation shifted from simply producing a story point to deciding whether the team knew enough for that estimate to mean something.

Formalizing the CUE Method

Before turning the practice into a method, I tried it with other teams that were also struggling with uncertainty. The situations were different, but the pattern was the same: stories with high uncertainty created similar delivery problems, and separating that uncertainty helped teams make better decisions about what they were ready to commit to.

The consistent results across those teams were the signal that the practice was worth formalizing. I began referring to it as the CUE Method.

The CUE Method is an Agile estimation method built around Complexity, Uncertainty, and Effort, with uncertainty acting as a gate that determines whether estimation should continue.

Complexity, uncertainty, and effort were already familiar considerations in story-point estimation. What was different in the practice we had developed was how uncertainty was treated. Instead of simply contributing to the size of an estimate, uncertainty was scored first and used to determine whether the team should continue estimating at all.

The name carries a second meaning too: a cue is a signal to act. That signal comes from the Uncertainty Gate.

The Uncertainty Gate

Uncertainty is always scored first. Before the team continues with its estimation process, it scores how much is still unknown about the story.

Before using the CUE Method, the team agrees on an uncertainty threshold: the point at which there is too much unknown to continue estimating. That threshold becomes the Uncertainty Gate.

• If the uncertainty score is below the threshold, that is the cue to continue with the team’s estimation process.
• If the uncertainty score reaches or exceeds the threshold, that is the cue to stop estimating and create a Spike.

When the gate is triggered, estimation stops. If the team is using all three factors in the CUE Method, complexity and effort are left unscored because what the team learns from the Spike could change both. The Spike focuses on the biggest unknowns so the team can learn what it needs before trying to estimate the story.

Once the Spike has reduced uncertainty below the threshold, the story can return to refinement and go through estimation again.

The purpose of the gate is not to eliminate all uncertainty before a story can be estimated. Some uncertainty will always remain. The gate simply marks the point where there is too much uncertainty to continue and the team needs to learn more first.

A Note on Uncertainty Spikes

A Spike may not always reduce uncertainty enough to continue estimating. It may also uncover new questions that require further investigation.

When that happens, the team should not automatically create another Spike. Before creating a second one, the team should be confident that the additional investigation is likely to reduce the story’s uncertainty. If confidence is low, the story should return to the product backlog for further refinement or decomposition with the Product Owner.

If the team believes a second Spike can reduce the uncertainty, it can proceed. However, Spikes should not become an endless cycle. If the uncertainty score is still at or above the threshold after the second Spike, no additional Spikes should be created. At that point, the story follows the same path back to the backlog.

The story can return to estimation once the Product Owner presents a revised version that is ready to be evaluated again.

Uncertainty Is Not the Same as Risk

Risk and uncertainty are related, but they are not the same.

Economist Frank Knight made this distinction in Risk, Uncertainty, and Profit in 1921. In simple terms, risk involves situations where possible outcomes and their likelihood can be estimated. Uncertainty exists when there is not enough information to make that assessment reliably.

That distinction matters in the CUE Method.

A risk is something the team can identify and discuss. A dependency may be delayed. A technical constraint may cause problems. An integration the team understands may still fail. The outcome is not certain, but the team understands enough about the possibility to consider it when estimating or planning the work.

Uncertainty is different. The requirements may still be vague. The team may be working with unfamiliar technology. An important dependency may not yet be understood. The team may not know enough about the work to judge what it will involve.

The CUE Method does not treat risk as unimportant, nor does it assume that risk is simply part of complexity or effort. Known risks can still affect the final estimate and can be handled through the team’s existing estimation and risk practices.

The Uncertainty Gate has a different purpose. It asks whether the team knows enough to continue estimating at all.

That is why uncertainty, rather than risk, triggers the gate.

This distinction was sharpened through feedback from Mike Cohn, who pointed me toward Frank Knight’s work on risk and uncertainty.

Where the CUE Method Fits

The CUE Method is not intended to replace story points, Planning Poker, or another estimation practice a team already uses. It also does not attempt to redefine every factor that may influence an estimate. Instead, it changes how uncertainty is handled by giving it a decision point before estimation continues.

A team can use the CUE Method simply as an uncertainty gate. If the uncertainty score is below the threshold, the team can continue with whatever estimation method it already uses. If uncertainty reaches or exceeds the threshold, estimation stops and the team learns more first.

Scoring complexity and effort separately is optional. Teams can add those two factors when they find value in discussing them independently.

Teams that choose to use all three factors can still use Planning Poker to discuss and agree on scores and story points as the final estimate. The three CUE Method scores provide a structured starting point, while known risks and other considerations can still be handled through the team’s existing estimation practices.

The CUE Method is also not something every team needs. It is most useful when teams regularly work with backlogs containing significant unknowns, unresolved dependencies, unfamiliar technology, unclear requirements, or other conditions that make stories difficult to understand before development begins.

For those teams, the value of the CUE Method is not simply another way to calculate a story point. Its value is giving uncertainty somewhere to go.

• Low uncertainty is the cue to keep estimating.
• High uncertainty is the cue to stop, learn, and come back when the team knows more.

That distinction changes where estimation begins. Not with how big the work is, but with what the team knows about it.

The next time your team is estimating a story, ask one more question:

How much uncertainty is there in the work we are estimating?

The answer may be the cue your team needs.