Definition

Planning poker is a consensus-based estimation technique where team members independently assign effort values to tasks before revealing their choices and discussing differences. It replaces the bias of vocal dominance with a structured process that surfaces hidden complexity and aligns the group on a shared understanding of work. By forcing individual thought before group discussion, you get more accurate forecasts for your sprint or release plan.

Why it matters for delivery

Estimation is the foundation of reliable delivery. If your numbers are wrong, your roadmap is fiction. Planning poker matters because it directly attacks the two biggest killers of accurate forecasting: anchoring bias and groupthink.

In a casual meeting, the first person to speak often sets the anchor. If a senior engineer says a feature takes 2 days, junior engineers may suppress their instinct that it will take 5, fearing they look incompetent or slow. The group converges on the wrong number quickly, and you ship late. Planning poker breaks this dynamic by requiring everyone to select a card simultaneously. You see the range of estimates before you hear the reasoning. This forces the team to discuss the outliers, not just agree with the loudest voice.

For product and engineering teams of 20 to 500 people, this discipline scales. It creates a shared language of effort across developers, designers, and QA. When everyone uses the same scale—whether Fibonacci, T-shirt sizes, or linear numbers—you reduce ambiguity. You stop arguing about ‘how long’ and start discussing ‘what is included.’ This clarity carries through to your timeline views, where accurate estimates allow you to model realistic dependencies and identify bottlenecks before they happen.

How it works in practice

The process is simple but requires discipline. You do not need special software, though digital tools help remote teams. Here is the standard flow:

• Select the item: Pull a user story or task from the backlog. Ensure the acceptance criteria are clear. If the scope is vague, the estimates will be noise.
• Clarify questions: The product owner or lead answers basic questions about functionality. Do not discuss effort yet. Focus on ‘what’ not ‘how long.’
• Estimate privately: Each team member selects a value based on their understanding of the work. In physical settings, this means picking a card. In Anabatic, you might use a private voting feature or a dedicated estimation board.
• Reveal simultaneously: Everyone shows their card at the same time. This prevents anchoring.
• Discuss outliers: If estimates match, move on. If they differ, the highest and lowest estimators explain their reasoning. Did the high estimator see a security risk? Did the low estimator assume a library exists? This discussion reveals missing requirements or technical debt.
• Re-estimate: After the discussion, the team votes again. Repeat until consensus is reached or the range is narrow enough to proceed.

The goal is not to find the ‘correct’ number. The goal is to ensure everyone has considered the same variables. If the team agrees on 8 points, but later finds out it takes 16, the process failed because the discussion missed a key constraint. The value is in the conversation, not the card.

A worked example with real numbers

Consider a feature request: ‘Add two-factor authentication (2FA) to the login flow.’ The team includes a frontend dev, a backend dev, a security specialist, and a QA engineer. They use a Fibonacci scale (1, 2, 3, 5, 8, 13) for story points.

Round 1:

• Frontend: 3
• Backend: 5
• Security: 13
• QA: 5

The spread is wide. The security specialist explains that 13 accounts for implementing FIDO2 standards, handling edge cases for lost devices, and ensuring compliance with new data privacy laws. The frontend dev assumed it was just adding a UI toggle for SMS codes. The backend dev missed the database schema changes needed for secure token storage.

Discussion:

The team realizes the scope was too broad. They split the story. Story A: ‘Implement SMS-based 2FA with basic recovery.’ Story B: ‘Implement FIDO2 hardware key support and advanced compliance logging.’

Round 2 (for Story A):

• Frontend: 3
• Backend: 3
• Security: 5
• QA: 3

Security still sees a 5 due to audit logging requirements. The team agrees to include basic logging in Story A but defer complex compliance reporting to a future technical debt ticket. The consensus settles on 5 points. This number now feeds into your velocity calculations. If your team averages 20 points per sprint, this task takes a quarter of a sprint, allowing you to plan other work around it accurately.

Common mistakes and how to avoid them

Teams often degrade planning poker into a guessing game or a political exercise. Avoid these pitfalls:

• Estimating time instead of effort: Story points measure complexity, risk, and effort relative to other tasks, not hours. A task might be simple but risky, warranting a higher point value. Do not convert points to hours directly. It breaks the abstraction and invites micromanagement.
• Skipping the discussion: If you vote and move on without discussing outliers, you lose the primary benefit. The value is in uncovering hidden dependencies or knowledge gaps. Force the conversation.
• Using too many values: A scale of 1 to 100 adds false precision. Stick to Fibonacci or T-shirt sizes. The difference between 8 and 13 is significant; the difference between 8 and 9 is noise. Keep it coarse enough to be useful, fine enough to be distinct.
• Letting managers vote: Managers should facilitate, not estimate. Their perspective on business value does not translate to technical effort. Their vote can skew the team toward pleasing leadership rather than reflecting reality.
• Ignoring the critical path: Estimation in isolation is useless. A task might be small, but if it blocks five other large tasks, its impact is huge. Always view estimates in the context of dependencies.

When you avoid these mistakes, planning poker becomes a diagnostic tool. It highlights where your team lacks knowledge or where requirements are unclear. Use the insights to refine your backlog, not just to fill a spreadsheet.

How it connects to the rest of your plan

Planning poker does not exist in a vacuum. The estimates you generate feed directly into your broader delivery strategy. Here is how they connect:

Velocity and Capacity: Your historical average of points completed per sprint (velocity) allows you to forecast future delivery. If you consistently complete 30 points, and your backlog has 120 points, you can predict a 4-sprint timeline. This accuracy builds trust with stakeholders and prevents overcommitment.

Roadmap Confidence: As you refine estimates, your timeline becomes more reliable. You can identify slack time—buffer periods where you can absorb delays without impacting the launch date. Without accurate estimates, you cannot calculate slack, and every delay becomes a crisis.

Gate Reviews: Before moving from design to development, use your estimates as part of the gate review. If a feature’s estimate exceeds the budget or timeline constraints, you can pivot early. This prevents wasting weeks on building something that is too expensive or risky.

Action Items: After the estimation session, capture any follow-up tasks. Did the discussion reveal a need for a spike (research task)? Did you identify a dependency on another team? Use an action items template to track these outcomes. This ensures that the insights from planning poker translate into concrete next steps, rather than evaporating after the meeting ends.

By integrating planning poker with your broader planning tools, you create a feedback loop. Estimates inform plans, plans reveal constraints, and constraints refine future estimates. This cycle drives continuous improvement in your delivery predictability.

Frequently asked questions

What is the best scale for planning poker?

The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is the most common. It reflects the increasing uncertainty of larger tasks. A task estimated at 21 is significantly riskier and less defined than one at 13. T-shirt sizes (XS, S, M, L, XL) work well for high-level roadmap planning where precision is less critical.

How long should a planning poker session take?

Aim for 1-2 minutes per story. If a task takes longer than 5 minutes to estimate, it is likely too complex or poorly defined. Split it into smaller stories or schedule a separate refinement session to clarify requirements before estimating.

Can remote teams use planning poker effectively?

Yes. Digital tools allow simultaneous voting and easy tracking of history. The key is to maintain the discipline of private estimation before discussion. Video calls can encourage premature anchoring, so use features that hide votes until everyone has submitted.

Who should participate in planning poker?

Everyone who will do the work should estimate. This includes developers, testers, and designers. The product owner facilitates and clarifies requirements but does not estimate effort. Managers observe to understand capacity but do not vote.