Kollabe
Retrospectives
Planning Poker
Standups
IceBreakers
Pricing
Dashboard

Posts

What is planning poker?

Agile team members each holding up an estimation card with a number on it, revealing their votes at the same moment around a table, in a clean modern illustration style
Matt Lewandowski

Matt Lewandowski

Last updated 21/06/20267 min read

Planning poker is a consensus-based estimation technique where everyone on the team privately picks a card to size a backlog item, then reveals all at once and talks through the gaps. The simultaneous reveal is the whole trick: nobody anchors on the senior engineer's number, so you get a more honest estimate and a sharper conversation about scope. It's also called Scrum poker or estimation poker. Whatever you call it, the goal is the same: a fast, fair way to agree on how big a piece of work is.
Also known as
Scrum poker, estimation poker, pointing poker
Introduced by
James Grenning in 2002, later popularized by Mike Cohn
Used for
Estimating the relative effort of backlog items
Best for
Sprint planning and backlog refinement with 3–9 people

How planning poker works

A round takes a couple of minutes. The structure is what makes it fair.
  1. Present the item
    The product owner reads out a backlog item and answers any quick questions about scope and acceptance criteria.
  2. Everyone picks a card privately
    Each person chooses the card that matches the effort they expect, based on complexity, unknowns, and risk. No peeking at each other.
  3. Reveal at the same time
    All cards flip together. Because nobody saw the others first, the spread reflects what people genuinely think.
  4. Discuss the outliers
    The highest and lowest voters explain their reasoning. This is where you uncover a missed dependency or a requirement people read differently.
  5. Re-vote until you converge
    Vote again with the new context. Most items settle in one or two rounds. You're aiming for close enough, not unanimous.
Selecting a vote card during a planning poker round in Kollabe The number you land on is a relative size, not a deadline. A 5 is roughly five times the effort of a 1. That's the point: teams are bad at guessing hours but good at saying "this is about twice as hard as that."

The cards: which deck should you use?

Most decks use a non-linear scale on purpose. The gaps between numbers force a real choice instead of endless debate over a 6 versus a 7.
DeckValuesBest for
Fibonacci1, 2, 3, 5, 8, 13, 21The default for most software teams
Modified Fibonacci0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100Adds room for "trivial" and "too big to estimate"
T-shirt sizesXS, S, M, L, XLEarly roadmap sizing and non-technical stakeholders
Powers of two1, 2, 4, 8, 16Teams who like a clean doubling scale
CustomWhatever you wantIdeal days, hours, or your own labels
Most teams settle on Fibonacci, and here's why those gaps matter so much. If you're torn between numbers and sizes, we compared T-shirt sizing and Fibonacci side by side. For a refresher on what the numbers actually represent, see our guide to planning poker story points.

Why teams use it

Planning poker survives because it fixes specific problems that show up the moment a group estimates out loud.
🎴Kills anchoring bias

Private votes mean the first number spoken doesn't drag everyone toward it. You see what people actually think.

💡Surfaces hidden assumptions

A wide spread is a signal, not a problem. It means two people read the same ticket differently, and now you'll find out before the sprint.

🙋Pulls in the quiet voices

Everyone votes, so the junior dev who spotted the gnarly edge case gets the same airtime as the loudest person in the room.

⚡Fast and repeatable

Once a team has a few reference stories, rounds take a minute or two. No spreadsheets, no drawn-out negotiation.

Revealed planning poker votes after a round, showing the spread of estimates across the team

When planning poker works, and when it doesn't

It's not the right tool for every situation. Knowing where it fits saves you from estimation theater. Reach for it when:
  • You're sizing items for an upcoming sprint and want shared understanding
  • The team is 3–9 people who'll do the work
  • Requirements are clear enough to discuss but still have unknowns
Skip it when:
  • You have 50+ items and limited time. Use affinity mapping or the bucket system instead
  • The work is fully understood and routine. Just assign a size
  • One person already knows exactly how to build it and nobody else will touch it

Running your first session

You don't need much to start. Pull up the backlog, agree on a couple of reference stories, and go.
  1. Pick a baseline
    Choose one small, well-understood story everyone agrees on and call it your reference. Common practice is to make it a 2 or 3, not a 1, so you have room to go smaller.
  2. Bring the right people
    Invite the people who'll build the work: developers, QA, and a product owner to answer scope questions. Keep it tight.
  3. Timebox each item
    Give a round a couple of minutes. If you're still split after two votes, note the open question, split the story, or park it for refinement.
  4. Record the estimate and move on
    Capture the agreed size and keep momentum. Estimation has sharp diminishing returns once you're in the right ballpark.
If a single item keeps splitting the room, that's usually a sign it's too big or too vague. Disagreement in planning poker is a feature, but a stubborn one often means the story needs breaking down in refinement first.

Planning poker with Kollabe

Kollabe is built around the part most teams actually care about: open a room, share the link, vote. No signup, no setup, no ticket import required. Most rooms run on the free tier and stay there. The depth is there when you want it. Anonymous voting hides cards until reveal, auto-reveal flips them when everyone's in, and async voting lets distributed teams estimate without a meeting. Pick a Fibonacci, T-shirt, or fully custom deck. Teams that live in a tracker can import tickets from Jira, GitHub, Azure DevOps, Linear, or CSV, sync winning votes straight back to story points, and let similar-round linking surface what comparable work scored in past sprints. Remote team members estimating together with avatars in a Kollabe planning poker room The easiest way to see it is to try the demo room. Pick a card, throw an emoji, and get a feel for it before you bring the team in.

It's a way for an agile team to estimate work together. Everyone secretly picks a card with a number on it, all the cards are revealed at once, and the team talks through any big differences until they agree on a size.

The gaps between Fibonacci numbers get wider as the values grow, which matches real uncertainty. Big tasks are genuinely harder to estimate, so forcing a jump from 8 to 13 (instead of agonizing over 9, 10, 11) reflects that the precision isn't really there.

Three to nine works best, ideally the people who'll do the work. Fewer than three loses the diversity of views that makes it valuable; more than nine slows discussion to a crawl.

No. It started in software, but any team estimating relative effort can use it: marketing campaigns, design work, or operational tasks. The technique cares about relative size, not what the work is.

Yes, and online tools often make it better. A digital deck handles the simultaneous reveal automatically, and async voting lets people estimate on their own schedule when a live call isn't worth it.