1 Overview
Planning poker is a group estimation technique in which participants privately choose a card representing a relative size for a backlog item, then reveal their choices at the same time. The simultaneous reveal is meant to prevent anchoring, where the first number spoken unduly influences everyone else. The numbers on the cards are typically drawn from a Fibonacci-like sequence, but the specific scale matters less than the conversation that follows. The real output is not the number itself but the assumptions, questions, and disagreements that surface when estimates diverge.
In practice, planning poker often appears inside backlog refinement or sprint planning. A facilitator reads an item, the product owner clarifies intent, and the team discusses what completing the item would involve. Each person then selects a card. When the cards are revealed, a wide spread triggers discussion: why did one person choose a small number and another a large one? Those differences usually point to hidden assumptions about scope, technical approach, dependencies, or acceptance criteria. The team may re-estimate after the discussion, but the estimate is secondary to the shared understanding that emerges.
Because planning poker is lightweight and requires no special tooling beyond a deck of cards or a simple app, it is widely used in agile teams. Yet its simplicity can be deceptive. Without skilled facilitation, it can devolve into a mechanical ritual that produces numbers without insight. The method works best when the team treats it as a conversation starter, not a scoring exercise.
2 The problem this method was built to solve
Software teams have long struggled to estimate how long work will take. Early approaches often relied on one expert—a lead developer or architect—to assign hours or days to each task. That created bottlenecks and often produced estimates that were optimistic or disconnected from the people doing the work. When estimates were wrong, blame followed, and trust eroded. Planning poker emerged as a way to distribute the estimation responsibility across the whole team and to make uncertainty visible rather than hidden.
The method also addresses a social problem: the tendency for the loudest or most senior voice to dominate. In a traditional meeting, the first person to speak can anchor everyone else. Planning poker’s simultaneous reveal gives quieter team members a chance to express their judgment without being swayed. It also surfaces disagreement early, when it is cheap to resolve, rather than late, when code is written and assumptions are baked in.
Another problem is the false precision of hour-based estimates. Planning poker typically uses relative sizes—small, medium, large, or a numeric sequence—rather than absolute time. This acknowledges that humans are better at comparing things than at predicting exact durations. The goal is not to produce a perfect forecast but to build a shared mental model of the work. When the team agrees on a relative size, they are also aligning on what the work entails, which is more valuable than the number itself.
3 How one cycle runs, from ready to done
A planning poker cycle begins with a backlog item that is considered ready for estimation. Ready means the item has a clear description, acceptance criteria, and any necessary context. The facilitator, often a scrum master or team lead, presents the item to the group. The product owner or a subject matter expert may answer questions. The team then discusses the item briefly, focusing on what is known and what is uncertain. This discussion is not meant to solve the problem but to expose assumptions.
After the discussion, each participant privately selects a card. When everyone is ready, the facilitator calls for a reveal. All cards are shown simultaneously. If the estimates are close, the team may accept the median or mode and move on. If there is a wide spread, the facilitator asks the outliers to explain their reasoning. This is the most valuable part of the cycle: the explanations often reveal that people are imagining different scopes, different technical approaches, or different definitions of done. The team may then re-estimate after clarifying. This can repeat once or twice, but the facilitator should timebox the discussion to avoid endless debate.
Once an estimate is agreed upon, the scribe records it along with any assumptions, open questions, or follow-up tasks. The item may then be considered estimated and ready for sprint planning. If the item is too large or too uncertain, the team may decide to split it or spike it—do a small investigation—before estimating again. The cycle ends when the team has a shared understanding and a recorded estimate, not necessarily a precise number.
4 Roles and how they divide the work
Planning poker involves several distinct roles, though in small teams one person may wear multiple hats. The facilitator guides the session, keeps time, and ensures everyone participates. This person should remain neutral and avoid influencing the estimate. The product owner or business representative presents the items, clarifies intent, and answers questions about value and priority. They help the team understand why the item matters, which can affect how much uncertainty is acceptable.
The estimators are the people who will do the work—developers, testers, designers, and anyone else who contributes to delivering the item. They are the ones who choose cards. Their diverse perspectives are the point: a tester may see edge cases that a developer overlooks, and a designer may spot usability concerns that affect effort. The scribe records estimates, assumptions, and action items. This role is often rotated to share the burden and to keep everyone engaged.
In some teams, a dedicated scrum master facilitates, while in others a rotating team member takes on the role. The key is that the facilitator does not also act as the primary estimator, because that can bias the discussion. The product owner should not estimate, as they are not doing the work; their role is to clarify. When roles are clear, the session runs smoothly and the team benefits from multiple viewpoints. When roles blur, the session can become a negotiation between the product owner and the team rather than a collaborative exploration.
5 Artifacts worth keeping
The most obvious artifact from planning poker is the set of estimates themselves. These are often recorded as story points, ideal days, or t-shirt sizes. But the numbers alone are of limited value. What matters more is the record of assumptions and open questions that emerged during the discussion. These notes help the team remember why they estimated a certain way and what they need to learn before starting work. They also provide a baseline for revisiting estimates if new information appears.
Another useful artifact is a list of items that need refinement or splitting. When an item receives a wide range of estimates, it often means the item is too large or too vague. The team may decide to split it into smaller pieces or to run a spike to investigate a technical unknown. Recording these decisions prevents the same item from being re-estimated repeatedly without progress. It also helps the product owner understand which items are not ready for planning.
Finally, the team may keep a lightweight estimation log that tracks how estimates compare to actual effort over time. This is not about performance evaluation but about calibration. If the team consistently underestimates certain types of work, they can adjust their approach. The log should be simple and owned by the team, not imposed by management. The goal is learning, not surveillance. Artifacts should serve the team’s understanding, not become bureaucratic overhead.
6 Where this method breaks down
Planning poker can become a performative ritual that produces numbers without shared understanding. When teams rush through items, skip discussion, or treat the estimate as the goal, the method loses its value. The numbers may look precise, but they rest on unexamined assumptions. This is especially common when planning poker is mandated by management or when the team feels pressured to deliver estimates quickly. In such cases, the session becomes a compliance exercise rather than a thinking tool.
Another breakdown occurs when the team focuses on effort rather than value. Planning poker estimates how much work an item requires, but it says nothing about whether the item is worth doing. A team can become very efficient at estimating low-value work. The product owner must ensure that the backlog is prioritized by value, and that estimation is not used as a substitute for prioritization. Otherwise, the team may spend hours estimating items that should be discarded.
Distributed teams face additional challenges. Without visual cues, simultaneous reveal can be awkward, and side conversations can exclude remote participants. Time zone differences make scheduling difficult, and asynchronous planning poker often loses the spontaneity that makes the method effective. Finally, planning poker can be slow. For teams with many items, the overhead of discussing and estimating each one can consume a significant portion of sprint planning. Some teams adopt alternative approaches, such as affinity estimating or silent sorting, to speed things up. The method is a tool, not a rule, and should be adapted or abandoned when it no longer serves the team.
7 Frequently asked questions
What if the team cannot agree on an estimate? Disagreement is useful. It usually means people have different assumptions about scope, approach, or risk. The facilitator should invite the outliers to explain their thinking, then ask the team to re-estimate. If disagreement persists, the item may be too large or too uncertain. Consider splitting it or running a spike. The goal is not forced consensus but shared understanding.
Should we estimate in hours or story points? Most agile teams prefer relative units like story points because they avoid false precision and focus on comparison. Hours can work if the team is stable and the work is well understood, but they often lead to debates about exact durations. The choice matters less than consistency and the conversation it generates.
How often should we do planning poker? It is typically done during backlog refinement, once per iteration or more often if new items are added. Some teams estimate continuously as items are refined, while others batch it. The cadence should match the team’s planning rhythm and not become a burden.
Can we skip planning poker if we already know the size? Yes. If an item is clearly small or clearly large, a full session may be unnecessary. The method is most valuable when there is genuine uncertainty or disagreement. Overusing it can waste time and dilute its benefits. Teams should feel free to use lighter-weight techniques for straightforward items.