Decision-Making Under Uncertainty: Estimate Game and Planning Poker

Some decisions feel clear.

Others do not.

Especially in projects, product development, change processes, or complex initiatives, there is often no complete certainty. Information is missing. Requirements change. Risks are not yet visible. And still, teams need to decide:

• How much effort is this?
• What is realistic?
• Where are the risks?
• What can we achieve in the next step?
• Which task is bigger than expected?
• Where do we agree – and where do we not?

This is exactly where structured estimation methods such as the Estimate Game or Planning Poker can help.

Not because they deliver perfect numbers, but because they make uncertainty visible.

Why estimating is not simply guessing

Many people associate estimates with vague numbers.

• “That will probably take three days.”
• “That feels rather small.”
• “That should be quick.”
• “That will be fine.”

The problem: statements like these often sound more certain than they actually are.

In complex situations, an estimate is not a truth. It is a shared approximation. It helps teams talk about effort, risk, complexity, and uncertainty.

Good estimates do not only answer the question:

• How long will this take?

They also answer:

• What do we already know?
• What do we not know yet?
• Which assumptions are we making?
• Which dependencies exist?
• Which risks might we be overlooking?
• Where do our estimates differ strongly?
• What do we need to clarify before we start?

Estimating is therefore less of a numbers game.

It is more of a learning process.

Why teams should decide differently under uncertainty

Under uncertainty, typical patterns appear quickly.

• One person states a number early. Others orient themselves around it.
• Experienced or louder voices shape the discussion.
• Risks are mentioned too late.
• Different assumptions remain invisible.
• Effort is underestimated because only implementation is considered.
• Clarification, alignment, quality assurance, or dependencies are left out.

This can lead to decisions that feel stable, but are built on shaky assumptions.

Methods like Planning Poker or the Team Estimation Game help reduce these effects.

Planning Poker works with hidden estimates that are revealed at the same time. This helps reduce anchoring: the first number mentioned does not immediately influence everyone else.

The Team Estimation Game works more comparatively. Tasks are estimated relative to one another: is this task bigger, smaller, or roughly the same size as another one?

Step by step, this creates a shared understanding of effort and complexity.

Estimate Game: comparing together instead of guessing alone

When people say Estimate Game, they often mean the Team Estimation Game.

It is an agile estimation method in which a team does not evaluate tasks or backlog items in isolation, but places them in relation to each other.

The basic idea is simple:

People are often better at comparing than predicting absolute effort.

It is difficult to say:

“This task will take exactly five days.”

It is easier to say:

“This task is bigger than task A, but smaller than task B.”

That is what the Estimate Game uses.

How the Estimate Game works

The exact process can vary from team to team. But in general, it follows these steps.

1. Prepare the tasks

First, collect the tasks, user stories, or backlog items that need to be estimated.

Important: the tasks do not have to be perfectly described. But they should be clear enough for the team to talk about them.

Helpful questions beforehand:

• What is the goal of this task?
• What is included?
• What is not included?
• Which questions are still open?
• Which dependencies are known?

2. Choose the first task as a reference

One task is used as a starting point.

It is not yet “right” or “wrong”. It only serves as a comparison point.

3. Place further tasks relatively

The team takes another task and asks:

• Is it smaller?
• Is it bigger?
• Is it roughly the same size?
• Why do we see it that way?

Over time, a sequence or grouping emerges.

4. Discuss differences

It becomes interesting where estimates differ.

If one person says “small” and another says “large”, that is not a problem.

It is the most important part of the method.

Different estimates often reveal different assumptions.

For example:

• One person is only thinking about implementation.
• Another sees technical risks.
• A third person is considering stakeholder alignment.
• A fourth knows about a dependency others have not seen.

5. Assign sizes

Once the tasks are sorted, relative sizes can be added.

For example:

• XS, S, M, L, XL
• 1, 2, 3, 5, 8, 13
• small, medium, large
• effort packages or complexity levels

Important: the scale itself matters less than the shared understanding behind it.

When the Estimate Game is especially useful

The Estimate Game is especially useful when:

• many tasks need to be roughly estimated
• the team needs a shared overview quickly
• not all details are known yet
• relative differences matter more than exact numbers
• the team has little experience with estimation
• discussions should not go too deep too early
• a backlog needs to be roughly sorted

It is often faster than Planning Poker because not every task has to be discussed individually in depth.

Practical tips for the Estimate Game

1. Do not go into details too early

The goal is not to fully analyze every task.

The goal is to create useful orientation.

If a discussion becomes too detailed, ask:

• What do we really need to know to estimate the relative size?
• Which details can we clarify later?
• Is this task maybe too unclear and needs refinement first?

2. Make uncertainty visible

Not every task needs to be estimated immediately.

If a task is too unclear, mark it consciously.

For example as:

• unclear
• needs clarification
• high risk
• dependent on a decision
• too large and needs to be split

That is not a failure of the method.

It is a result.

3. Keep reference tasks

It helps to keep a few reference tasks for the team.

For example:

• A typical small task
• A typical medium task
• A typical large task

This makes the scale easier to understand.

4. Pay attention to quiet voices

If only two people estimate, it is not a team estimate.

Make sure quieter people are included as well.

Helpful questions are:

• Who sees this differently?
• Which perspective is missing right now?
• Are there risks we have not discussed yet?
• What would make this task bigger?

Planning Poker: estimating without anchoring

Planning Poker is a consensus-based estimation method that is especially common in agile teams.

Team members estimate a task secretly, often using card values such as 1, 2, 3, 5, 8, 13 or T-shirt sizes. Then the cards are revealed at the same time and differences are discussed.

The advantage: nobody creates an anchor with the first number.

Everyone first has to think for themselves.

This makes different perspectives visible and protects the team from following a dominant opinion too quickly.

How Planning Poker works

1. Present the task

A task, user story, or work package is briefly presented.

Important: everyone should roughly understand what it is about.

Not everything has to be clarified down to the last detail. But the goal, scope, and open questions should be clear enough.

2. Clarify understanding

The team asks questions.

For example:

• What is the desired result?
• Which acceptance criteria exist?
• Are there technical or business risks?
• Who is involved?
• Which dependencies exist?
• What is not part of the task?

3. Everyone estimates secretly

All participants choose a card or number at the same time.

Important: do not discuss numbers beforehand.

Otherwise, an anchor is created again.

4. Reveal all estimates at the same time

All estimates become visible.

Now the team can immediately see:

• Are we close together?
• Are there strong deviations?
• Did someone see a risk others missed?
• Is the task perhaps less clear than we thought?

5. Let the highest and lowest estimates explain

It is especially helpful to let the people with the highest and lowest estimate speak first.

Not as a justification.

As a learning moment.

Useful questions are:

• What did you take into account?
• Which assumption is behind your estimate?
• Which risk do you see?
• What makes it smaller from your perspective?
• What makes it bigger?

6. Estimate again

After the discussion, the team estimates again.

Usually, the estimates move closer together.

If they do not, that is a signal: real uncertainty remains.

Then consensus should not be forced artificially.

When Planning Poker is especially useful

Planning Poker is especially useful when:

• individual tasks should be estimated more carefully
• different perspectives are important
• the team needs to develop a shared understanding
• technical or business risks should be discussed
• strong opinions are present
• anchoring effects should be avoided
• decisions should not be shaped only by hierarchy or loud voices

Planning Poker is therefore not only an estimation method.

It is also a conversation structure.

Estimate Game vs. Planning Poker: what fits when?

Both methods help teams make decisions under uncertainty. But they focus on different things.

Estimate Game is a better fit when …

• many tasks need a rough classification
• speed is important
• relative sizes are enough
• the team first needs an overview
• a backlog should be sorted or prepared
• details are not fully clear yet

Planning Poker is a better fit when …

• individual tasks need more detailed discussion
• consensus is important
• assumptions and risks should become visible
• different estimates already exist in the team
• the team is preparing for a sprint or concrete implementation
• decisions need to become more binding

In short:

Estimate Game helps with sorting.
Planning Poker helps with deepening.

What both methods can achieve

Both methods help teams deal better with uncertainty.

They make visible:

• different assumptions
• blind spots
• risks
• dependencies
• unclear points
• complexity
• different levels of experience
• need for discussion

That is often more valuable than the number itself.

Because an estimate is only as good as the conversation it creates.

What both methods cannot do

It is also important to know the limits.

Neither the Estimate Game nor Planning Poker makes the future predictable.

They do not replace:

• clear priorities
• good refinement
• business clarification
• technical analysis
• stakeholder alignment
• clean decisions
• regular review
• learning from real data

Estimation methods are not an oracle.

They are tools that help teams think better together.

Common mistakes when estimating

1. Treating estimates like commitments

An estimate is not a guarantee.

If an estimated task becomes bigger later, it does not automatically mean someone worked badly.

Maybe the uncertainty was higher than visible. Maybe requirements changed. Maybe the team learned something.

Better:

• treat estimates as assumptions
• document assumptions
• reassess when new information appears
• do not look for blame, look for learning

2. Talking about numbers too early

If someone immediately says “That is three points at most”, it influences the group.

Even unconsciously.

So in Planning Poker:

First clarify.
Then estimate secretly.
Then discuss.

3. Confusing confidence with truth

A confident estimate is not automatically the best estimate.

Pay attention especially to quiet signals such as:

• “I am not sure, but …”
• “Could it be that …”
• “Have we considered that …”
• “I still see a dependency here …”

Important risks often appear exactly there.

4. Estimating tasks that are too large

If a task is huge, the estimate becomes inaccurate.

More discussion does not help then.

Splitting does.

Ask:

• Can we cut the task smaller?
• What is the first deliverable part?
• What is clarification?
• What is implementation?
• What is risk analysis?

5. Not reviewing estimates afterwards

Teams only learn if they later look at what actually happened.

After completing a task, briefly reflect:

• Was our estimate helpful?
• What did we overlook?
• What was smaller than expected?
• What was bigger?
• Which reference will help us next time?

This builds estimation competence.

First steps for applying it yourself

You do not need a perfect setup to start.

What matters is that you use the method consciously and do not just produce numbers.

1. Choose the right occasion

Ask yourself:

• Do we need to roughly sort many tasks?
• Or do we need to understand a few tasks more deeply?

For many tasks: Estimate Game.
For fewer, more concrete tasks: Planning Poker.

2. Prepare the tasks well enough

Not perfectly. But understandably.

For each task, the team should know:

• What is the goal?
• What is the expected value?
• What is included?
• What is open?
• Which dependencies are known?

If this cannot be answered, the task may not be ready for estimation yet.

3. Agree on a scale

Use a simple scale.

For example:

• XS, S, M, L, XL
• 1, 2, 3, 5, 8, 13
• small, medium, large
• low, medium, high

The scale itself is not the key.

What matters is that the team understands it together.

4. Talk about assumptions

After every noticeable estimate, ask:

• Which assumption is behind this?
• What would need to be true for this estimate to fit?
• What could make it bigger?
• What could make it smaller?
• What do we not know yet?

This makes uncertainty visible.

5. Document more than the number

Briefly capture:

• estimate
• most important assumptions
• open questions
• risks
• next clarification step

That is often enough.

A number without context quickly loses its value.

6. Use timeboxing

Estimation sessions can expand endlessly.

Set clear time windows.

For example:

• 2 minutes to present the task
• 3 minutes for questions
• 1 minute for estimation
• 5 minutes for discussion if estimates differ
• 1 re-estimation

If there is still no clarity after that, the task is probably too unclear or too large.

Then the result is:

Not estimable yet – clarify first.

7. Make estimating a learning process

After a few weeks, ask:

• Where were we close?
• Where were we off?
• Which tasks were hard to estimate?
• Which signals did we miss?
• Which reference tasks will help us in the future?

This does not only make the team faster.

It makes the team better at dealing with uncertainty.

Small exercise: make uncertainty visible

Before the next estimation, add one simple question:

“How confident are we in this estimate?”

For example with three levels:

• high confidence
• medium confidence
• low confidence

This is helpful because two tasks can have the same effort, but very different levels of uncertainty.

Example:

• Task A: 5 points, high confidence
• Task B: 5 points, low confidence

Both look the same size. But task B may first need clarification, an experiment, or a spike.

Conclusion

Decision-making under uncertainty does not mean pretending everything is clear.

It means making uncertainty visible and manageable together.

Estimate Game and Planning Poker help with exactly that.

The Estimate Game helps teams quickly classify tasks relative to each other.

Planning Poker helps teams understand individual tasks together, make different assumptions visible, and reduce anchoring effects.

Both methods are effective when they are not treated as a numbers game.

But as a conversation about:

• effort
• complexity
• risks
• assumptions
• dependencies
• learning needs

In the end, the most important question is not:

“What number do we give this task?”

It is:

“What did we understand better because of this estimate?”