The CUE Method FAQ

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. Uncertainty is scored first. If it is too high, the team stops estimating and creates a Spike instead of producing a story point.

Because missing knowledge is different from known difficulty or volume of work. When a team does not yet understand what the work involves, any estimate of complexity or effort is unreliable. The CUE Method makes that lack of knowledge visible and actionable.

Risk and uncertainty are related, but they are not the same. A risk is something the team can identify and assess even though the outcome is not certain. Uncertainty exists when the team does not know enough about the work to make that assessment reliably.

The CUE Method does not ignore risk or assume that it is part of Complexity or Effort. Known risks can still be considered through the team’s existing estimation and risk practices. Uncertainty gets special treatment because too much missing knowledge can make the story premature to estimate.

No. The CUE Method is designed to work with existing practices. Many teams use it simply as an Uncertainty Gate and then continue with their normal estimation method. Scoring all three factors is optional.

It is the uncertainty threshold the team agrees on before using the CUE Method: the point at which there is too much unknown to continue estimating. When uncertainty reaches or exceeds that threshold, the team creates a Spike instead of assigning story points.

The team decides. What matters is that everyone agrees on the threshold and applies it consistently, not the number itself. The sample working agreement in How to Run an Estimation Session using the CUE Method uses 8 on the Fibonacci scale, which is a reasonable place to start. Adjust it later if experience shows a different threshold works better for your context.

No. You can use the CUE Method in a minimal form: score only Uncertainty and apply the gate. If the story passes the gate, continue with whatever estimation method you already use. Full three-factor scoring is useful when the team wants more structured discussion.

The simplest and most common approach is to take the arithmetic mean of the three scores, then use a quick confidence vote.

• High confidence → round to the nearest Fibonacci number
• Lower confidence → round up to the next Fibonacci number

Some teams discuss the three scores and then run a final Planning Poker round instead of averaging. Both approaches work if the team is consistent.

When the team is roughly evenly divided on whether the story is above or below the threshold, treat it as above the threshold and create a Spike. Favor learning when the room is divided.

Maximum of two. Before creating a second Spike, the team should believe it is likely to bring uncertainty below the threshold. If uncertainty is still high after two Spikes, return the story to the Product Owner for further refinement or splitting. Do not create a third.

That is common. The Spike rules still apply: do not automatically create another Spike. First decide whether a second investigation is likely to reduce uncertainty enough. If not, send the story back for refinement.

No. The CUE Method is most useful when the backlog regularly contains significant unknowns, unresolved dependencies, unfamiliar technology, or unclear requirements. Teams that already have high clarity and predictability usually do not need it for every story.

Here is sample language you can adapt.

• Uncertainty Gate. We treat an uncertainty score of 8 or higher as too high to estimate.
• Definition of Ready. A story is ready for estimation only when its uncertainty score is below the agreed threshold, or a Spike has been completed that brings it below.
• Spike Rules. Spikes are time-boxed. Maximum of two Spikes per story. A second Spike requires confidence that it will reduce uncertainty below the threshold.

Start with only the Uncertainty Gate for two or three sprints. Keep your existing estimation method. Add Complexity and Effort scoring later only if the team finds the extra conversation valuable.