Planning Poker: The Art of Team Estimation

An estimation session disguised as a card game. Spoiler: it's far more effective than a spreadsheet.

What is Planning Poker?

Planning Poker (also called Scrum Poker) is a collaborative estimation technique used by agile teams. Each team member privately picks a numbered card that represents how big they think a user story is, then everyone reveals their card at the same time. When the numbers diverge, the people holding the highest and lowest cards explain their reasoning, and the team votes again until the estimates converge.

The values on the cards usually follow a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. We'll come back to why.

The key thing to understand is that Planning Poker doesn't estimate durations. It measures the relative size of a piece of work compared with other pieces of work, expressed in story points. That distinction is fundamental. You don't say "this will take 3 days". You say "this is roughly twice as complex as that other story we estimated at 3".

In one sentence: Planning Poker is a consensus-based estimation game in which every team member votes privately and simultaneously, so that disagreements surface and get discussed before anyone writes a line of code.

Where does Planning Poker come from?

The technique was created by James Grenning in 2002. A developer and agile coach, and one of the signatories of the Agile Manifesto, Grenning was looking for a way to involve the whole team in estimation, not just the two or three most senior people in the room.

His original paper, Planning Poker or How to avoid analysis paralysis while release planning, describes a problem most teams will recognize: in traditional planning, estimates are often produced by a single expert or a small group, which leaves blind spots and leads to long, unproductive debates. Grenning combined three ideas:

Expert-based estimation (inspired by Wideband Delphi): every participant estimates independently.
Simultaneous reveal: estimates are shown at the same moment, so nobody is influenced by anyone else.
Structured discussion: gaps between estimates trigger a conversation before the next vote.

Mike Cohn then popularized the technique in his book Agile Estimating and Planning (2005), which made it a staple of the Scrum toolbox. Since then, it has become one of the most widely used estimation methods in agile teams around the world.

Who takes part in a Planning Poker session?

You don't need much to play, but each role matters:

The developers, in the broad Scrum sense: everyone who builds and tests the product. They are the ones who vote, because they are the ones who will do the work.
The Product Owner presents the stories, explains the business need and answers questions. They usually don't vote.
A facilitator, often the Scrum Master, keeps the pace, launches each vote and makes sure every voice gets heard.
A deck of cards for each voter, physical or virtual.

For the full breakdown of roles, card values and edge cases, see our complete guide to Planning Poker rules.

How does a Planning Poker session work?

As the Scrum Guide describes, sprint planning is when the team decides what it will deliver next. Planning Poker fits naturally into that event, or into the backlog refinement sessions that come before it (our practical guide to sprint planning covers the bigger picture). A round goes like this:

The Product Owner presents a user story. They read the description and the acceptance criteria and answer the first questions. The goal is for everyone to understand what is being asked.
The team discusses briefly. Developers ask technical questions, spot dependencies and clarify grey areas. A few minutes, no more.
Each participant picks a card in secret, representing their estimate of the story's size.
Everyone reveals at the same time. This is the moment of truth.
If the estimates diverge widely, the team talks. The person with the lowest card and the person with the highest card explain their reasoning. These exchanges are often the most valuable part of the whole session.
The team votes again until it reaches consensus, or at least a number everyone can live with.

In practice, most stories converge in one or two rounds. A story that needs three rounds or more is usually poorly defined and would benefit from being split.

If you are the one running the session, our Scrum Master guide to running a Planning Poker session covers preparation, timeboxing and how to handle divergent votes.

A worked example

Here's what a typical round looks like. The Product Owner presents this story: "As a user, I want to reset my password by email so that I can get back into my account without contacting support."

Five developers pick their cards and reveal: 3, 3, 5, 5, 13.

The facilitator asks the two extremes to speak first. One of the developers who voted 3 explains: "We already send transactional emails. It's a form, a token and a template." The developer who voted 13 replies: "Our email provider doesn't handle the token expiry we need, and the security team will want rate limiting on that endpoint. Last time we touched authentication, the review alone took days."

Nobody else had thought about rate limiting or the security review. The team votes again: 5, 8, 8, 8, 8. The story is recorded at 8, and the Product Owner adds an acceptance criterion about rate limiting.

The final number matters less than what happened along the way: a hidden risk surfaced in two minutes instead of halfway through the sprint.

Why the simultaneous reveal changes everything

The simultaneous reveal is the heart of the system. It prevents conformity bias: if the senior developer announces "8" first, everyone else is likely to follow without thinking. When everyone votes at the same time, each person stays honest about their own perception.

The mechanism also counters a well-documented effect in social psychology: anchoring. The first number spoken in a discussion pulls every following estimate toward it. Planning Poker neutralizes that effect by removing the sequence altogether. Nobody hears a number before choosing their own.

Disagreements are gold. A gap between a 2 and a 13 means the team doesn't share the same understanding of the story. That's exactly what you want to discover before you start coding.

Which card scale should you use?

Several scales are used in Planning Poker:

Modified Fibonacci (1, 2, 3, 5, 8, 13, 21): by far the most common. The widening gaps reflect the growing uncertainty on bigger stories. Learn why agile teams use Fibonacci.

Linear (1, 2, 3, 4, 5...): more intuitive, but problematic. It suggests you can tell a 7 from an 8, a level of precision that is illusory on complex work.

Powers of 2 (1, 2, 4, 8, 16, 32): used by teams that want even starker gaps than Fibonacci. Less common, but effective at forcing clear-cut decisions.

On top of the numbers, most decks include special cards:

0: the story is trivial or already done.
? (question mark): "I don't have enough information to estimate."
Coffee cup: "We need a break."

Many online tools, ours included, also offer a ½ card for very small tasks and let you switch to T-shirt sizes when numbers feel too precise.

Planning Poker vs other estimation techniques

Planning Poker isn't the only agile estimation technique. Depending on the context, another approach may fit better.

T-Shirt Sizing (XS, S, M, L, XL): ideal for early scoping, or for teams not yet comfortable with story points. Faster and less precise, perfect for a quarterly roadmap. Read our dedicated T-Shirt Sizing guide.

Dot voting: each participant gets a limited number of dots to spread across tickets. It isn't really a size estimate, more a prioritization tool. Useful when the team needs to decide what to do first rather than how much it costs.

Affinity mapping: the team sorts tickets into columns on a board, from smallest to largest, without assigning any numbers. Values are added afterwards. Very effective for sizing a large backlog in one go (30 or more tickets in an hour).

Bucket system: a fast variant where tickets are dropped into numbered buckets (0, 1, 2, 3, 5, 8, 13, 20+). Each participant takes a ticket and places it in a bucket, and disagreements are handled at the end. Suited to very large backlogs.

For a side-by-side comparison of all these methods, including the #NoEstimates approach, see our guide to agile estimation techniques for sprint planning.

Common Planning Poker mistakes

After dozens of sessions, the same traps keep coming back:

1. Estimating in disguised days. "It's a 5 because it'll take me 5 days." No. Story points measure relative complexity, not duration. If your team thinks in days, estimates get skewed by differences in experience between team members. Our comparison of story points vs person-days explains why.

2. Letting the Product Owner vote. The PO presents the stories; they don't size them. Their vote can unintentionally sway the team ("if the PO says 3, it must be quick"). The PO joins the discussion but doesn't show a card.

3. Chasing consensus at all costs. The goal isn't for everyone to agree. It's for everyone to share the same understanding of the story. If after two rounds the spread narrows from 2-13 to 5-8, that's good enough. Take the higher value or the median and move on.

4. Averaging the votes. Turning a 3, a 5 and a 13 into a 7 hides the disagreement instead of resolving it, and produces a number that isn't even on the scale.

5. Estimating too many stories in one session. Beyond 60 to 90 minutes, fatigue sets in and estimate quality drops. Short, frequent sessions beat three-hour marathons.

6. Having no reference story. Without a point of comparison, every estimate starts from scratch. Pick a reference ("that login story we shipped last month is a 3") and compare everything to it.

7. Ignoring the special cards. When someone plays the "?" card, it isn't laziness. It's a signal that the story is missing information. The worst thing you can do is force an estimate on a vague ticket.

When NOT to use Planning Poker

Planning Poker isn't a universal tool. In some situations, other approaches work better:

When the backlog is huge. Estimating 80 tickets with Planning Poker would take hours. For a large initial backlog, start with T-Shirt Sizing or affinity mapping, then refine with Planning Poker as stories get closer to a sprint.

When the tickets are all alike. If your team handles repetitive, well-understood work (standard bug fixes, near-identical API integrations), Planning Poker adds little. The team already knows the size, and a quick call from the tech lead is enough.

When the team is very small (2 or 3 people). Planning Poker draws its strength from a diversity of perspectives. With only two developers, a direct conversation is more natural and faster.

When there's no Product Owner to present the stories. Without business context, purely technical estimates miss half of the equation. Postpone the session rather than estimate blind.

Running Planning Poker with a remote team

Planning Poker was born around a physical table, but it works just as well with a distributed team, as long as you compensate for what video calls take away: eye contact, energy and the shared ritual of flipping cards together. A dedicated tool keeps votes hidden until the reveal, a facilitator keeps the rhythm, and a strict timebox protects everyone's focus.

We cover tools, facilitation tips and the asynchronous variant in our guide to Planning Poker for remote teams.

Planning Poker and AI

Can AI estimate your stories for you? Not really, and that isn't where it helps most. AI is useful before the session: sharpening user stories, drafting acceptance criteria and flagging missing information, so the team spends its time on the discussions that matter. The vote itself stays human, because the value of Planning Poker lies in the shared understanding the team builds while voting.

Lessons from the field

"We started by estimating everything. Now we're more selective." Many teams begin by estimating every ticket, including minor bugs and technical chores. Over time, most of them focus on significant stories and leave small tickets unestimated. The effort-to-value ratio is much better.

"The biggest gains come from the discussion, not the number." This is the most common feedback. The number on the card is almost secondary. What counts is the moment a developer says "wait, did you think about the database migration?" and everyone realizes the story is twice as big as expected.

"We stopped discussing beyond two rounds." Some teams cap discussions at two rounds. If there's still no consensus, they take the higher value and move on. The result: sessions half as long, with no noticeable loss of accuracy.

"Going remote changed how we play." For distributed teams, online tools have replaced physical cards. The unexpected bonus is that votes can be exported and kept, so you can look back at how your estimates evolved over time.

Tools to play Planning Poker

Physical cards: for co-located teams. Nothing beats flipping a real card on the table. Buy a deck, or simply write the values on sticky notes.
Planning Poker Online: our free online tool, built for remote and hybrid teams. Create a session in one click, share the link and estimate in real time, with no account required. Discover all the features: simultaneous voting, synchronized reveal, Fibonacci, T-shirt or powers-of-2 scales, and CSV or PDF export of your estimates.
Jira extensions: several plugins integrate Planning Poker directly into your Jira backlog.

Still choosing? Our comparison of free planning poker tools puts price, ads, sign-up, participant limits and Jira support side by side.

The best tool is the one your team will actually use. A quick round of raised fingers beats a sophisticated tool that nobody opens.

Frequently asked questions

Is Planning Poker the same as Scrum Poker? Yes. Scrum Poker, Planning Poker and pointing poker are different names for the same technique: private votes, simultaneous reveal, discussion of the gaps.

How long should a Planning Poker session last? Aim for 60 to 90 minutes at most, and just a few minutes per story. If one story takes more than ten minutes, it probably needs to be clarified or split first.

Does the Product Owner vote in Planning Poker? Usually not. The Product Owner explains the story and answers questions, but only the people who will build it vote.

What if the team can't reach consensus? After two or three rounds, take the higher estimate or split the story. A disagreement that won't go away is a sign the story isn't understood well enough yet.

Can you use Planning Poker without Scrum? Yes. Any team that sizes work collaboratively can use it, whether you run Scrum, Kanban with regular refinement sessions, or no formal framework at all.

Start your first Planning Poker session

Planning Poker is a simple tool, but its power lies in what surrounds it: alignment, knowledge sharing and a shared mental model of the work ahead. Used well, it makes your sprint planning faster and your estimates more reliable.

Ready to try it? Create a free Planning Poker session in a few seconds. No sign-up required: share the link with your team and start estimating.