What is planning poker? A complete guide for agile teams

Planning poker (also called Scrum poker) is a way for an agile team to estimate a piece of work together. Each person picks a card with a number on it in private, everyone reveals at the same moment, and the people with the highest and lowest cards explain their thinking. The team then votes again or agrees on a number, usually in story points, and moves on to the next item.

It works because it separates thinking from talking. Nobody can anchor on the first number said out loud, the quietest person’s view counts as much as the most senior person’s, and the gap between the cards shows exactly where the team understands the work differently. This guide covers the rules, the cards, the history, a worked example and the mistakes to avoid.

How does planning poker work?

A planning poker session is a series of short rounds, one per backlog item. Teams usually play it during backlog refinement, the regular meeting where they get upcoming work ready for a sprint. Each round follows the same steps:

1. Present the item. The product owner reads the user story or backlog item and its acceptance criteria. A minute or two is enough; the detail comes out in questions.
2. Clarify. The team asks about scope and expected behaviour. Nobody mentions sizes or numbers yet.
3. Choose in private. Each estimator picks the card that matches their view of the item’s size and keeps it face down (or, online, hidden).
4. Reveal together. Everyone turns their card over at the same moment.
5. Discuss the extremes. If the cards differ, the people with the highest and lowest cards explain what they were picturing. Often one of them knows something the others do not.
6. Vote again or agree. The team re-votes after the discussion. One to three rounds is usually enough for the cards to come together.
7. Record and move on. The agreed estimate goes on the item, along with any assumption the team made, and the next item starts.

If everyone shows the same card on the first reveal, there is nothing to discuss: record it and move on. Those rounds can take less than a minute. The time goes on the items where the team disagrees, which is exactly where it should go.

The cards

The cards limit the values people can choose. Most decks use a sequence that starts close together and spreads out, such as this modified Fibonacci deck:

• 0
• ½
• 1
• 2
• 3
• 5
• 8
• 13
• 20
• 40
• 100
• ?

The widening gaps are deliberate. Telling a 2 from a 3 is realistic; telling a 34 from a 38 is not, so the deck does not ask you to. Many decks also include special cards: ? for “I can’t estimate this yet”, a coffee cup for “I need a break” and sometimes ∞ for “too big to estimate”. The full set is covered in planning poker cards and decks explained.

The numbers are usually story points: a relative unit that blends effort, complexity and uncertainty. A 5 is bigger than a 3 and smaller than an 8. It is not five hours.

Who takes part

• The developers estimate. Everyone who will do the work votes: programmers, testers, designers, data engineers. The 2020 Scrum Guide puts it plainly: “The Developers who will be doing the work are responsible for the sizing.”
• The product owner explains, but does not vote. They describe the item, answer questions and decide on scope. If an estimate comes out bigger than hoped, they can offer a smaller version of the item.
• A facilitator runs the rounds. Often the Scrum master. They keep time, make sure the extremes are heard and stop discussions turning into design sessions. Many online tools call this role the moderator.
• Observers can watch. Stakeholders and new joiners can sit in without voting, which is a good way to learn how the team thinks about size.

Why does planning poker work?

Planning poker looks like a game, but each rule is there to fix a specific problem with estimating in a group.

It uses relative estimation

Most people find it hard to predict how many hours a piece of work will take, and much easier to compare: “this looks about twice the size of the login change we did last month.” Planning poker asks for exactly that kind of judgement. Teams keep a few reference stories with agreed sizes and place each new item relative to them, which keeps estimates consistent from one session to the next.

It stops anchoring

When someone says a number out loud, other people’s estimates drift towards it. Psychologists call this anchoring. In a well-known 1974 study, Amos Tversky and Daniel Kahneman asked people to estimate the percentage of African countries in the United Nations after watching a wheel of fortune stop at either 10 or 65. The median guesses were 25% and 45%: a number that had nothing to do with the question still pulled the answers.

In a refinement meeting the anchor is rarely random. It is the tech lead saying “that’s a quick one”, or the product owner hoping for a small number. Choosing cards in private and revealing them together means every first estimate is independent.

It surfaces what people know

A spread of cards is not a problem to smooth over; it is information. When one developer plays a 3 and another plays a 13, they are rarely disagreeing about effort. They are picturing different work: the high voter has spotted a data migration, a performance limit or a missing test environment, or the low voter knows a shortcut. Asking the highest and lowest voters to explain turns those private assumptions into shared understanding.

Everyone takes part

Because every estimator has to put a card down, quieter team members contribute as much as confident ones. James Grenning, who first described the technique, put it like this:

“The whole team plays the game, not just the most vocal, or most senior.”

What the evidence says

Research on planning poker is limited but encouraging. In a 2007 field study, Kjetil Moløkken-Østvold and Nils Christian Haugen introduced planning poker for half of the tasks in a real software project. For those tasks, the team’s consensus estimates were less optimistic, and more accurate, than a mechanical combination of the individual estimates. Experts estimating a separate set of tasks on their own were about as accurate, so the fair conclusion is that planning poker is a good way to combine opinions, not a guarantee of better numbers.

Where did planning poker come from?

Planning poker has its roots in the Delphi method, a forecasting technique developed at the RAND Corporation in the 1950s and 1960s, in which experts estimate anonymously and revise their answers over several rounds. In the 1970s Barry Boehm and John A. Farquhar created a variant for estimating software work, Wideband Delphi, which added more discussion between rounds (the “wideband” refers to that extra communication). Boehm’s 1981 book Software Engineering Economics made it widely known.

The card game itself came from James Grenning, one of the authors of the Agile Manifesto. In 2002 he was facilitating a planning meeting for an Extreme Programming team in American Fork, Utah, and watched it stall while the two most senior people debated each story and everyone else drifted off. That year he wrote up his fix in a short paper, “Planning Poker or How to avoid analysis paralysis while release planning”. Each programmer wrote an estimate on a card without discussing it, the cards were turned over together, and the people at the extremes started the discussion.

His original deck had just seven cards: 1, 2, 3, 5, 7 and 10 (unitless, or in ideal programming days) and infinity. If a story would take longer than two weeks, you played infinity and the customer had to split it. Grenning reported that stories which had taken 10, 20 or 30 minutes each to estimate now mostly took about a minute.

Mike Cohn then brought planning poker to a much wider audience, particularly Scrum teams, through his 2005 book Agile Estimating and Planning. His teams also shaped the deck most people now think of as standard: they found that 21 implied a precision they could not support, so they used 20, and later added 40 and 100 for very large items.

A worked example: one round from start to finish

Here is how a typical round might go for a team building an invoicing web app. Lena is the Scrum master and facilitator, Sam is the product owner, and five people vote: Priya, Tom, Marek, Jo and Aisha, who leads on testing. Their reference stories are “Download a single invoice as a PDF” (3 points) and “Email reminders for overdue invoices” (8 points). Sam reads the item:

As a finance manager, I want to export a month’s invoices as a CSV file, so that I can reconcile them in our accounting software. Acceptance criteria: one row per invoice; invoice number, customer, date, net, VAT and gross amounts; works for accounts with up to 50,000 invoices a month.

Two quick questions settle which date to use (the issue date) and which currency (the account’s own). Then everyone picks a card.

After the first reveal, Lena asks the extremes to speak. Tom (3) says the invoice table is already on screen, so the export is a button and a CSV writer, about the same as the PDF download. Aisha (13) points out that the screen loads 500 rows at a time. At 50,000 invoices the request would time out, so the export has to run in the background and email a download link, and she wants to test it on a large account.

Marek adds that the team already has a background job queue for monthly statements, so that part is mostly reuse. Sam confirms that only a handful of accounts are that large, but the requirement stands. In the second round the cards close up around 8. Lena asks Marek, the one remaining 5, whether he can live with an 8. He can, so the team records 8 with a note: “Assumes we reuse the statements job queue.”

The round took a few minutes and produced more than a number: a hidden requirement (the timeout), a shortcut (the existing queue) and a written assumption that makes the estimate easy to revisit if it turns out to be wrong.

When does planning poker work well, and when doesn’t it?

Planning poker earns its time when there is real uncertainty to talk about and enough shared context to talk about it. It works well for:

• Refined items of small to medium size, where the team understands the goal and the acceptance criteria.
• Cross-functional teams, where developers, testers and designers each see different parts of the work.
• New or changing teams, which need to build a shared sense of what a 3 or an 8 means.
• Remote teams, because an online tool makes the private vote and the simultaneous reveal easy.

It is the wrong tool, or needs help, when:

• You have a hundred items to size at once. Use a faster technique, such as affinity estimation or the bucket system, for a first pass, then use planning poker on the items you are about to build.
• The item is an epic. If the cards land on 40 or 100, split the item before estimating it.
• Nobody knows enough yet. A pile of ? cards means the item needs research (a spike) or a conversation with someone outside the room.
• Estimates are used to judge people. If points become targets or are compared between teams, people start voting defensively and the numbers stop meaning anything.

Some teams decide they get enough from slicing work small and counting items, and stop estimating altogether. That is a legitimate choice, and worth discussing in a retrospective if estimating has started to feel like a ritual.

Remote and async planning poker

Planning poker moved online easily, because its core mechanic, a private vote followed by a simultaneous reveal, is simpler to enforce on screen than across a table. A remote round runs the same way as an in-person one: the facilitator shares the item, everyone votes in a browser tab, and the tool reveals all the cards at once. A few habits help: read the item aloud rather than assuming everyone has read it, keep cameras on for the discussion if your team is comfortable with that, and if even one person is remote, have everyone vote in the tool, including the people sitting together. There is more in remote planning poker.

Async planning poker goes a step further. Instead of meeting, everyone reads the items and votes on their own time before a due date, often with a short comment explaining their card. The team then meets briefly to discuss only the items where the votes were spread. It suits teams across time zones and saves meeting time for the hard items, at the cost of some live discussion. The guide to async planning poker explains how to set it up.

On planningpoker.org You can start a free session in your browser without an account. A guest session holds up to 8 people, the host included: the others join by link with just a name, and guest sessions are deleted after 24 hours. Votes stay hidden until everyone’s cards are revealed together. A free Laya account adds Async Poker, where everyone votes before a due date and the team reviews the results together.

Common planning poker mistakes

• Averaging the cards. If the votes are 3, 3 and 13, the average (about 6) hides the fact that one person sees a problem the others have missed. Talk first. If you still have to pick a number mechanically, the median is safer than the mean.
• Saying sizes before the reveal. “This one’s tiny” is an anchor, even when it is said kindly. Keep size words out of the clarifying questions.
• Letting the product owner or a manager vote. The people doing the work should size it. A product owner who votes is, in effect, negotiating.
• Estimating hours in disguise. If “one point equals one day” is the unspoken rule, you have lost the benefit of relative estimation. Compare with reference stories, not the calendar.
• Debating forever. If two rounds have not brought the cards together, the item is probably too big or too unclear. Split it, spike it or park it.
• Pressuring the outlier. The person with the odd card is often right. Ask what they are seeing before asking them to change.
• Treating estimates as promises. An estimate is the team’s best judgement on the day. Turning it into a deadline makes the next estimate bigger and less honest.

How to get started with planning poker

You do not need special equipment or a long training session. For a first session:

1. Pick a deck. Modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ?) is a sensible default.
2. Choose two or three recently finished items the team remembers well and agree their sizes, for example a 2, a 5 and a 13. These are your reference stories.
3. Ask the product owner to prepare six to ten refined items with acceptance criteria.
4. Book 45 to 60 minutes, explain the rules in two minutes and run a practice round on something light before the real items.
5. After three or four sessions, use a retrospective to ask whether the estimates are helping you plan, and adjust.

The facilitator’s side, from preparing the backlog to a sample agenda and introducing the technique to a sceptical team, is covered in how to run a planning poker session, step by step.