How to Run an Estimation Session using the CUE Method

The CUE Method is not a replacement for Planning Poker or story points. It is a structured way to surface uncertainty before the team commits to a number.

Read The Estimation Problem That Led Me to the CUE Method first. It is where the method comes from, and it explains why uncertainty gets a score of its own. This one picks up where that piece leaves off and assumes you have read it. The CUE Method FAQ answers the questions that come up most often.

A prioritised story goes to the team, who discuss it and score uncertainty first, with complexity and effort held back. The score meets the Uncertainty Gate. Below the threshold the story continues to estimating and on to a sprint commitment. At or above it, the story takes a Spike and returns to the team.

When to Use the CUE Method

The CUE Method is most useful when your backlog regularly contains:

Unclear or incomplete requirements
External dependencies that are not yet resolved
Unfamiliar technology or approaches the team has not used before
Stories that historically carry over or expand once work begins

If your team already delivers most of what it commits to and rarely encounters major unknowns, a simpler estimation approach is usually enough. The CUE Method adds the most value when uncertainty is a frequent source of missed commitments.

Prepare the Team

Before the first session, agree on a few working agreements. Here is sample language you can adapt.

Sample working agreements

Uncertainty Gate: We treat an uncertainty score of 8 or higher on the Fibonacci scale 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.

Running the Session, Step by Step

1. Review the story together

The Product Owner, or anyone presenting the story, briefly explains the intent and any known acceptance criteria. The team asks clarifying questions as usual.

2. Score uncertainty first

Everyone privately selects a Fibonacci number that represents how much is still unknown about the story. Common anchors:

1-3 → We understand the work well enough to estimate reliably
5 → Some important questions remain, but we can still make a reasonable estimate
8+ → Too many unknowns; we should not estimate further

Reveal the scores. Discuss outliers the same way you would in Planning Poker. Reach consensus on a single uncertainty score.

3. Apply the Uncertainty Gate

A story is scored on complexity, uncertainty and effort, with uncertainty scored first. It reaches the Uncertainty Gate. Below the threshold the story continues to an estimate. At or above the threshold it stops and takes a Spike.

Below the threshold → continue to complexity and effort, or to your normal method if the CUE Method is only your gate.
At or above the threshold → stop estimating and create a Spike. No complexity or effort score yet.

4. Score complexity and effort

This step is optional. If the story passes the gate, the team can score the two remaining factors or continue with its existing estimation method.

Complexity: how difficult is the work itself? Technical difficulty, number of moving parts, cognitive load.
Effort: how much work is involved once the approach is clear? Volume of changes, testing, coordination.

Again use the Fibonacci scale, and discuss outliers.

5. Combine the three scores

Take the arithmetic mean of the three, then a quick confidence vote: fist of five, thumbs, or high, medium and low.

High confidence: round the average to the nearest Fibonacci number.
Lower confidence: round up to the next Fibonacci number.

The average is arithmetic. The vote is what catches the doubt the three scores did not manage to express, and rounding up is where that doubt lands.

That becomes the final story point estimate. When the average falls between two Fibonacci numbers, the confidence vote is what decides which one it lands on.

Some teams prefer to discuss the three scores and then run a final round of Planning Poker instead of averaging. Both work, as long as the team is consistent.

6. Record the outcome

The final story points
The individual factor scores, which are optional but useful for later review
Any Spike that was created, with its time box and the questions it must answer

Real World Example

Story: “As a customer, I want to see real-time inventory from our warehouse system so I know whether an item is available before I order.”

The team knows the warehouse has an API, but no one has used it yet. The data format is unclear, authentication is unknown, and the other team has not confirmed when the API will be stable.

Uncertainty scores: 8, 13, 8, 5, 8 → Consensus: 8 Gate triggered. Complexity and Effort are not scored.

Spike created (time-boxed to 1 day): “Confirm authentication method, sample response payload, and rate limits of the warehouse inventory API.”

After the Spike, the team re-scores: Uncertainty is now 3. The story returns to estimation.

New scores:

Complexity: 5
Uncertainty: 3
Effort: 8

Average = (5 + 3 + 8) ÷ 3 = 5.33 Confidence is high → rounds to 5.

Final estimate: 5 points, because high confidence rounds to the nearest Fibonacci number. Had confidence been lower, the same 5.33 would have rounded up to 8.

Handling Spikes

The decision rules

Time-box every Spike, normally one to two days or a fixed number of hours.
Write down the questions it has to answer.
Maximum of two Spikes on the same story.
Before a second Spike, the team must believe it is likely to bring uncertainty below the threshold.
If uncertainty is still at or above the threshold after two Spikes, return the story to the Product Owner for splitting or further refinement. Do not create a third.

Facilitator Tips

Estimation sessions using the CUE Method may take a little longer per story at first, but that time can pay off through fewer carry-overs and clearer sprint commitments.

When the team is split on whether uncertainty has reached the gate, treat it as above the threshold and create a Spike. When the team is divided, favor learning over estimating.

If a Product Owner pushes to estimate a high-uncertainty story anyway, the team should return to its Definition of Ready. If the story has not passed the Uncertainty Gate, it is not ready to be estimated. The working agreement applies regardless of urgency or priority.

After two or three sprints, use the retrospective to ask whether scoring all three factors is adding value. Some teams may decide to keep only the Uncertainty Gate.

Integrating with Existing Practices

You can introduce the CUE Method gradually. Both of these are valid.

Two ways in

Minimal: Use only the Uncertainty Gate. If the score is low enough, carry on with Planning Poker or whatever you already use.
Full: Score all three factors and combine them as described above.

Known risks do not need their own CUE Method score. Teams can continue to consider risk through their existing estimation and risk practices. The Uncertainty Gate serves a different purpose: determining whether the team knows enough to estimate the story in the first place.

Common Pitfalls to Avoid

Treating the Uncertainty Gate as optional when a story feels important or urgent
Creating Spikes that are not time-boxed, or that lack clear questions
Letting Spikes multiply without a decision point
Using the CUE Method on every story even when the team already has high clarity and predictability
Forgetting to update the Definition of Ready, so the practice never becomes part of how the team works

Start Here

Do not try to adopt the full method on day one.

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

The most important shift is simple.

Make “we do not know enough yet” a legitimate and respected outcome of estimation.

When the team can say that out loud and act on it, estimation stops hiding uncertainty and starts managing it.