Planning guide

15 min read

How to Run Your First Planning Poker Session

The number at the end matters. The conversation that produces it matters more.

A cross-functional team simultaneously revealing their Planning Poker estimates around a table

The vote is useful. The discussion is the main event.

Planning Poker is often introduced as an estimation technique. That is true, but incomplete. The real value is not the number at the end. It is the conversation that happens before the number becomes credible.

A good session helps a team: discover hidden assumptions, share technical context, challenge unclear requirements, educate less experienced team members, and expose risks before work begins.

Your first session does not need to be perfect. It needs to be honest, structured, and safe enough that people are willing to say what they really think.

What Planning Poker actually is

Planning Poker is a collaborative estimation technique used by agile teams to estimate the relative size of backlog items or user stories. The basic flow is straightforward:

A backlog item is presented

The team asks clarifying questions

Each participant privately selects an estimate

Everyone reveals their estimate at the same time

Differences are discussed openly

The team re-votes or agrees on an estimate

The estimate and key assumptions are captured

Where did it come from?

Planning Poker has roots in Wideband Delphi — an expert-estimation technique designed to reduce the influence of dominant voices and improve forecasting through structured rounds of independent judgement and discussion. Planning Poker makes that idea lighter, faster, and easier to use inside software teams.

Why simultaneous reveal?

The simultaneous reveal is important. It stops the first speaker — the most senior engineer, architect, manager, or loudest personality — from accidentally anchoring everyone else's estimate. Every person gets a moment to think independently before the group starts influencing itself.

What Planning Poker is not

It is worth being clear about this, especially in teams where estimation has been used as a planning tool or performance mechanism.

Planning Poker is not…

A hidden way to extract hour commitments from developers
A negotiation tactic to make work fit into a sprint
A substitute for product judgement
A performance measurement tool
A ceremony where the number matters more than the discussion

If your team leaves with a number but no shared understanding, the session was weak. If they leave with a number, clearer assumptions, better questions, and visible risks — the session did its job.

Why the discussion matters more than the vote

The most useful moment in Planning Poker is often the gap between estimates. One person votes 3. Another votes 13. That difference is not a problem. It is information.

Maybe the low estimate assumes a simple UI change. Maybe the high estimate includes database migration, permissions, audit logging, regression testing, or rollout risk. Maybe one person has seen a similar feature fail before. Maybe a junior developer is missing context that a senior engineer takes for granted.

The vote creates the signal. The discussion creates the value.

More than estimation

Planning Poker becomes a structured way to exchange knowledge across roles and experience levels. A frontend developer learns why the backend team is worried about query performance. A junior developer learns which edge cases senior people watch for. A tester highlights scenarios nobody mentioned. The Product Owner discovers that a story that sounded simple is carrying three hidden requirements.

Who should attend your first session?

Keep the group focused, but make sure the right perspectives are present.

Product Owner

Or whoever understands the business objective and can explain what outcome matters.

Developers

The people likely to work on the item. Their perspective on effort and risk is central.

QA / Testing

If testing is separate, their input on acceptance criteria and edge cases is valuable early.

UX / Design

When the item has significant user-facing design impact or unresolved interaction decisions.

Architecture / Platform

When the item touches security, data, integrations, or system-level concerns.

Facilitator

A Scrum Master, delivery lead, or neutral team member who can manage process without owning outcome.

Avoid filling the session with observers who are not directly involved in understanding or delivering the work. The people doing the work should estimate the work.

Preparation matters more than people think

A slow Planning Poker session is often blamed on the estimation method. Usually, the real problem is poor preparation. If the team spends ten minutes trying to understand what a story even means, that is not Planning Poker failing. That is backlog readiness failing.

Before the session, prepare a focused set of backlog items — not the entire backlog, not vague ideas. Each item should have enough context to support a useful discussion.

The goal is not to remove all uncertainty. The goal is to provide enough context that the team can identify the important uncertainty.

Each item should answer:

What problem are we solving?
Who is it for, and what outcome matters?
What is explicitly in and out of scope?
What acceptance criteria or examples exist?
Are there designs, flows, or customer examples available?
Are there known dependencies or integration points?
Are there security, performance, compliance, or migration implications?
Is this delivery work, discovery work, technical debt, or a defect?

Use reference stories before you start

For a first session, reference stories are extremely helpful. Pick a few completed or well-understood items and use them as calibration points.

Without reference stories, people often estimate from instinct. With reference stories, they estimate relatively. The question changes from 'How big is this?' to 'Is this bigger or smaller than the thing we already understand?' That is a much better conversation.

pts1

A small text and validation change

pts3

A standard API and UI change

pts5

An SSO-related change touching auth, frontend, backend, and tests

pts8

A reporting change with data migration and performance risk

Choose a simple estimation scale

Fibonacci scale

Most teams use a Fibonacci-style scale. The growing gaps acknowledge that uncertainty grows with size. It is not worth debating whether a large item is 20 or 21 — the real question is whether it is small enough to understand, or should be split.

123581321

T-shirt sizes

A useful alternative when a team is new to estimation or the work is still too early for detailed story points. XS, S, M, L, XL. Relative sizing without committing to a number.

XSSMLXL

Do not let the team secretly translate points into hours. Once people say 'one point equals half a day,' the method starts to collapse. Story points reflect relative effort, complexity, risk, and uncertainty. Velocity may later help with forecasting — but the estimate itself should not become a disguised timesheet.

The scale matters less than the discipline around it.

A simple agenda for your first 60 minutes

Time	Activity
0–5 min	Explain the purpose and ground rules
5–10 min	Calibrate with reference stories
10–45 min	Estimate selected backlog items
45–55 min	Review unresolved items, risks, and splits
55–60 min	Quick retrospective on the session itself

0–5 min

Explain the purpose and ground rules

5–10 min

Calibrate with reference stories

10–45 min

Estimate selected backlog items

45–55 min

Review unresolved items, risks, and splits

55–60 min

Quick retrospective on the session itself

Do not try to estimate 40 items in your first session. Start with 5 to 10. Learn how the team behaves. Adjust from there.

Step-by-step: how to run the session

Set the frame

Start by explaining the purpose. People need to know disagreement is welcome and that it has boundaries.

"The goal today is not perfect estimates. The goal is shared understanding. If estimates differ, that is useful — it means we have assumptions to discuss. Challenge the work, challenge the assumptions, but not the person."

Present the backlog item

The Product Owner or item owner should explain what the item is, why it matters, who benefits, what outcome is expected, and what is in and out of scope. Do not just read the ticket aloud. Everyone can read. Use the time to explain intent.

Let the team ask clarifying questions

Before voting, the team should ask questions. Good questions check scope, dependencies, edge cases, permissions, migration needs, and release requirements. At this stage, ask the team to hold their estimates until the private vote. Even casual comments — 'This is probably small' or 'We only have two days, so it has to be a 2' — introduce bias before the vote happens.

Vote privately

Each participant selects an estimate privately. No one explains their estimate yet. No one hints. No one performs confidence or doubt for the room. This is where Planning Poker protects independent judgement.

Reveal at the same time

Everyone reveals their estimate together. The reveal is not the answer — it is the start of the useful part. If everyone is close, you may already have agreement. If the spread is wide, slow down. The difference is telling you something.

Ask the outliers to explain

Ask the highest and lowest voters to explain their reasoning. Not to defend themselves. Not to win. Just to expose assumptions. What did they include? What risk are they seeing? What would need to be true for the estimate to be lower?

Discuss, then decide the next action

Planning Poker should allow real discussion. It should not become an uncontrolled design workshop. A useful facilitator prompt: 'Do we need to solve this now to estimate the item, or should we capture it as a follow-up?' After discussion, vote again — or choose from: accept the estimate, split the item, mark it not ready, create a spike, capture an open question, or escalate a product decision. Do not force a number onto work the team does not understand. 'Not ready' is a valid outcome.

Capture more than the number

Record the final estimate, key assumptions, major risks, dependencies, scope decisions, and open questions. This becomes valuable later. When a 3-point item turns into a week of pain, you can inspect why. That is how teams improve.

How to handle disagreement

Disagreement is not failure. Silence is more dangerous. A team willing to challenge assumptions is usually a sign of health — people care enough, and feel safe enough, to say what they see. The goal is a team that challenges weak assumptions — not a team that turns every estimation into a design session. Knowing the difference is most of the facilitator's job.

Type of challenge	Example	What to do
Clarification	"I do not understand what this means."	Clarify context or mark as not ready.
Scope challenge	"This is actually three stories."	Split the item or reduce scope.
Risk challenge	"This touches billing and permissions."	Discuss the estimate impact.
Product challenge	"Why are we doing this at all?"	Let the PO explain the objective. Park deeper strategy.
Technical design debate	"We should implement it differently."	Continue only if it materially affects size or risk.
Quality concern	"This creates a security or reliability issue."	Treat seriously. It may block readiness entirely.

Clarification

"I do not understand what this means."

Clarify context or mark as not ready.

Scope challenge

"This is actually three stories."

Split the item or reduce scope.

Risk challenge

"This touches billing and permissions."

Discuss the estimate impact.

Product challenge

"Why are we doing this at all?"

Let the PO explain the objective. Park deeper strategy.

Technical design debate

"We should implement it differently."

Continue only if it materially affects size or risk.

Quality concern

"This creates a security or reliability issue."

Treat seriously. It may block readiness entirely.

A facilitator guiding a distributed team through a Planning Poker session on screen

The Product Owner's role: negotiate scope, not reality

This is one of the most important parts of running Planning Poker well. The Product Owner should not pressure the team into a lower estimate.

If the team says the full version is 13 points, saying 'Can we make it a 5?' does not change reality.

But the Product Owner absolutely can negotiate scope.

Scope negotiation, not estimate pressure

"If the full version is a 13, what is the smallest useful version we could deliver as a 5?"

Engineering should not be forced to pretend work is smaller than it is. But engineering should also not use estimation as a veto over business priorities. The business objective still matters. The customer still matters.

The best sessions respect both sides: Product explains why the work matters. Engineering explains what the work really involves. Together, they shape a version worth doing.

The role of the facilitator

A good facilitator is not a referee counting cards. They protect the quality of the conversation. They can be a Scrum Master, agile coach, delivery lead, team lead, or rotating team member. The important thing is neutrality.

A facilitator makes sure:

Nobody anchors the vote early
Quiet people are invited in
Senior people do not dominate
Juniors are not embarrassed for asking basic questions
Discussion stays relevant to the estimate
Unresolved items are not forced through
Outcomes are captured

Useful facilitator phrases

"Let's hear from someone who has not spoken yet."
"What assumption is driving the difference?"
"Are we discussing the estimate, or are we designing the solution?"
"This sounds important, but not needed for the estimate. I'll park it."
"The spread is still too wide. This item is probably not ready."
"Can the Product Owner reduce scope, or do we need to split this?"

Running Planning Poker asynchronously

Distributed teams across time zones do not always need to estimate together in real time. Async Planning Poker can work well — if you protect the discussion.

Product Owner prepares items with full context

Team members review items independently, at their own pace

Each person submits a hidden estimate

The tool highlights items with agreement and items with wide spread

The team only meets to discuss the disagreements

Watch out

Async voting should not remove the discussion — it should focus the discussion where it matters most. The danger is treating async estimation as a form submission exercise. The value is still in understanding the differences.

Common challenges worth knowing about

Senior people dominate

This is common and easy to prevent. Enforce private voting, simultaneous reveal, and structured outlier discussion. Do not let senior people estimate out loud before the vote. Their experience is valuable. Their early anchoring is not.

The team debates too long

Usually means the item is too vague, too large, or the team is solving implementation details too early. Ask: 'Do we need this discussion to estimate, or should we capture it as a follow-up?' If the team still cannot converge, mark the item as not ready.

The Product Owner pushes for a lower number

Understandable, but dangerous. The Product Owner can ask to reduce scope. They should not pressure the team to reduce the estimate without changing the work. The rule is simple: negotiate scope, not reality.

The team skips the outlier discussion

One of the easiest ways to destroy the value of Planning Poker. If someone votes much higher or lower than the group, ask why. That explanation may be the most important contribution in the session.

Everything becomes hours

A sign the team does not yet trust relative estimation. Bring the conversation back to comparison: 'Is this more like the login change, the reporting change, or the SSO change?' That question returns the discussion to where it belongs.

Juniors copy seniors

Happens when estimates feel like a test. Make it clear: estimates are not about being right. They are about surfacing assumptions. A junior developer voting differently can be extremely valuable — it may reveal missing context or an unclear requirement.

What makes the first session work

Your first Planning Poker session should not be judged by how many numbers you produce. Judge it by the quality of the conversation.

Did the team understand the work better? Did hidden assumptions become visible? Did juniors learn from seniors? Did the Product Owner get better information for scope and priority decisions? Did the team challenge weak assumptions without losing control?

Planning Poker is not valuable because teams enjoy voting on cards. It is valuable because independent estimates create the conditions for better discussion. The number matters. The conversation matters more.

Run Planning Poker with your whole team

Ibis Flow makes it easy to run Planning Poker sessions — structured votes, simultaneous reveal, backlog linking, and captured assumptions all in one place. Try it free for 14 days.

Start free trial

See estimation features