Where planning poker fits in the sprint cycle
Planning poker is an estimation technique, not a planning technique—an important distinction. It belongs in backlog refinement (also called grooming), not in the sprint planning meeting itself. By the time the team sits down to commit to a sprint goal, stories should already be estimated.
The rough rule: estimate stories when they are two sprints away from being worked. That window gives the team enough context to discuss meaningfully without wasting effort on stories that will change or disappear. Estimating in sprint planning—under time pressure with a half-built backlog—leads to rushed points and low-quality discussion.
Before the session: what makes stories ready to estimate
Running poker on unready stories wastes everyone's time. A story is ready to estimate when it has:
- A clear user goal — who benefits and what they can do when the work is done.
- Written acceptance criteria — at least the happy path, ideally edge cases too.
- Surfaced dependencies — APIs, design deliverables, or other teams the story needs.
- A size that fits a sprint — if the team agrees it is epic-sized, split it first.
The Product Owner is responsible for story readiness before refinement. If stories are not ready, defer them rather than estimating on incomplete information.
Choosing the right deck for your team
Most teams start with Fibonacci (1, 2, 3, 5, 8, 13, 21…). The growing gap between numbers reflects a real truth: the larger a piece of work, the harder it is to estimate precisely. A "13" is not just a bigger "8"—it carries significantly more uncertainty.
If your team is new to estimation or works with non-technical stakeholders, T-shirt sizing (XS, S, M, L, XL) is friendlier to explain and produces a useful first pass. You can always map sizes to points later. See the Fibonacci vs T-shirt sizing guide for a detailed comparison.
Avoid asking teams to estimate in hours—it collapses the distinction between effort, complexity, and uncertainty into a number that implies false precision.
Facilitation checklist: running the session
- Open the room and share the link early. Send it in Slack before the meeting. Guests and stakeholders should join before you start the first story.
- Product Owner reads the story aloud. Then takes questions—no estimates yet. This clarification phase typically takes 3–5 minutes per story and is where most misunderstandings surface.
- Facilitator counts down: 3, 2, 1, reveal. Simultaneous reveal is the key mechanic. It prevents anchoring—nobody sees a "5" and moves their "8" to match before the count.
- Highest and lowest estimators explain first. Not to argue, but to share mental models. Often the high estimate reveals a technical risk; the low estimate reveals a simpler approach nobody had considered.
- Re-vote if needed. One more round usually converges. If the team cannot agree after two rounds, either split the story or accept the higher estimate and note the uncertainty.
- Capture the result immediately. Write the agreed point value in your tracker before moving to the next story—do not trust "we'll update it later."
Timeboxing: how many stories can you cover?
A well-run refinement session can cover 8–15 stories in 60–90 minutes, assuming they are ready to estimate. Roughly 5–8 minutes per story for discussion plus a quick re-vote when needed. Factors that slow you down:
- Stories that lack acceptance criteria (send them back, do not estimate them).
- Outliers that spark long architectural debates (timebox at 10 minutes, then defer or split).
- Technical spikes masquerading as stories (spike them separately, then estimate).
If you have 20+ stories, run two separate refinement sessions across the week rather than one 3-hour marathon. Cognitive fatigue degrades estimate quality significantly by the second hour.
Handling outlier votes constructively
When the vote spread is wide—say, a 2 and a 13 on the same story—that spread is information, not a problem. It means the team has different mental models of the work. Good questions to ask:
- "What would need to be true for this to be a 2?"
- "What are you worried about that pushed you to 13?"
- "Do we agree on the acceptance criteria, or is someone interpreting the scope differently?"
Resist the urge to average. A 2 and a 13 averaged to 7.5 resolves the conflict on paper while hiding the real disagreement. Surface it, discuss it, then vote again.
Remote-specific tips
Remote refinement works well with the right habits in place:
- Video on for discussion phases. Facial expressions matter when someone explains why they voted 13. Mute during silent estimation—background noise disrupts focus.
- Keep a back-channel for clarifications. A Slack thread alongside the video call lets late-joiners catch up without interrupting the current story.
- Paste the story link in chat before reading it aloud. People read faster than you speak; having the text visible cuts re-reads and "can you repeat that."
- End each story with a written note. Drop the agreed estimate and a one-sentence rationale into the story's comments. Async teammates who missed the call can follow the reasoning.
When to skip planning poker
Not every story needs a full poker round. Good candidates for fast-tracking:
- Copy tasks: The team unanimously agrees on the size before anyone reveals. A single consensus vote suffices.
- Recurring chores: Dependency upgrades, certificate renewals, standard releases—batch these at a fixed point (e.g. always a 1 or 2) after the first time.
- Bug fixes with obvious scope: A well-understood one-line fix with a clear repro does not benefit from five minutes of poker.
Use your judgment. Planning poker is a tool to surface disagreement and build shared understanding—when neither is needed, skip it.
Connecting estimates to velocity and sprint capacity
Once stories are estimated, sprint planning becomes a capacity exercise: the team selects stories until the total points match the team's recent average velocity. Use a rolling 3-sprint average rather than a single sprint peak—velocity varies, and padding the sprint with aspirational capacity sets teams up for failure.
If your team is new and has no velocity history, start conservatively. Run one sprint, measure the actual throughput, and calibrate from there. The first estimation numbers do not need to be accurate; they need to be consistent relative to each other.
Start your next session in ScrumJam
Open a room from the new session page, paste the link into your team's Slack channel, and run through the checklist above. When you want to import your Jira backlog directly into the session, see the Jira integration page. For deeper technique, pair this guide with agile scrum estimation practices and the planning poker handbook.