Planning poker is a way for an agile team to size work together. Everyone picks a card with a number in secret, all the cards turn over at once, and the people with the highest and lowest numbers explain why. Then the team votes again. One to three rounds usually settle it. It works because it drags hidden work and risks into the open before anyone commits to a sprint.
This guide covers where planning poker came from, how a session runs, who should be in the room, when to hold one and what goes wrong. It also covers where planning poker stops being enough: when you need hours and a budget, not points.
James Grenning described planning poker in 2002. He was running a planning meeting for an Extreme Programming team, and it had stalled. The two most senior people argued back and forth while everyone else tuned out. His fix was simple: everyone writes an estimate in silence and shows it at the same moment, so no single voice sets the number before the others have thought about it.
Mike Cohn of Mountain Goat Software later made the method widely known through his book Agile Estimating and Planning.
Planning poker is an estimation technique built on consensus. Each voter gets an identical deck. A common deck holds 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 (Mountain Goat Software). The numbers are usually story points: a relative measure of how much work, complexity and risk an item carries compared with other items. A 5 is bigger than a 3, and nobody pretends to know the exact hours.
The gaps between the numbers grow on purpose. Cohn explains it with Weber’s law: people notice differences as a percentage, so 1 kg and 2 kg are easy to tell apart, while 20 kg and 21 kg are not. After 2, each Fibonacci number is about 60% larger than the one before it (Cohn on the Fibonacci scale). His team swapped 21 for 20 and added 40 and 100, because the bigger numbers suggested more precision than anyone had.
If story points are new to you, start with what story points are and how to estimate them.
Managers and clients can watch, but they shouldn’t vote or push numbers. A sponsor who says “that should be a 3” turns planning poker back into the meeting Grenning was trying to fix.
Skip it for a long backlog that only needs rough sizes. Sort those items into groups first (affinity estimation) and save planning poker for the work you’ll build soon.
Every voter gets the same deck, on paper or in a tool. Agree on two things before you start. First, what a 1 or a 3 looks like: pick a finished story as the reference. Second, what you’ll do if the votes are still split after three rounds.
The product owner reads the story and its acceptance criteria aloud.
The team asks questions. Which screens and services does it touch? What data does it need? What could break? What’s still unclear? Keep it short. The goal is a shared picture of the work, not a design session.
Everyone picks a card face down. The facilitator calls the reveal, and all the cards turn over at once.
If the numbers match or sit next to each other on the scale, record the estimate. If not, the highest and lowest voters speak first. The high number often points to hidden work or a risk. The low number may point to a simpler design or a part that already exists. Then everyone votes again.
If the team still can’t agree, take the higher number or split the story. Settle that rule before the session, not in the middle of an argument.
| Problem | What it looks like | What to do |
|---|---|---|
| Anchoring | Someone says a number before the reveal | Reveal at the same moment every time; the facilitator stops early numbers |
| Points turned into hours | “One point is half a day” becomes a rule | Use velocity for sprint plans; estimate hours separately, only for budgets |
| Endless debate | Twenty minutes on one story | Cap each item at a few minutes; split the story or plan a short research task |
| Huge cards | 40 or 100 shows up often | The story is too big; split it before you size it |
| Pressure from outside | A manager asks for lower numbers | Managers watch, they don’t vote; cut scope, not the estimate |
| Comparing teams | Team A does 40 points a sprint, team B does 25 | Points mean something only inside one team; compare each team with itself |
AI tools now suggest estimates too. A 2026 study tested four large language models on 16 software projects. With no training data at all, the models predicted story points better than deep learning models trained on 80% of each project’s data, and a few examples from the project made them better still (Shetty et al., 2026).
That doesn’t make the meeting useless. A model doesn’t know that your payment provider’s test environment is slow, or that the one person who understands the billing code is on leave next month. Treat an AI number as one more card on the table: a starting point the team agrees with or argues against. The Scrum Guide Expanded makes the same point about forecasting tools in general: they help, but they don’t replace learning from what the team actually delivers.
Velocity still needs real data. Jira’s velocity chart, for example, averages the work a team completed over its recent sprints, counted in story points, hours, work items or another number field you pick (Atlassian). The forecast gets more reliable as sprints pile up. Before the team has finished a few, it tells you very little.
Planning poker answers “how big is this story compared with that one?” for a team that already exists. A founder deciding whether to build needs a different answer: how many hours, how much money and how many weeks. Points can’t give that, because a point only means something inside one team.
Our project estimate starts from the same raw material, user stories, and turns them into hours:
Here is an example run of our estimate’s math with sample inputs: a B2B SaaS web app with teams, roles and subscription billing. The work items and the business numbers are assumptions. Only the arithmetic is ours.
| Phase | Hours |
|---|---|
| Discovery and UX: roles, workflows, wireframes | 18 |
| Design: design system and main screens | 20 |
| Frontend: workspace, lists, admin and settings | 56 |
| Backend: multi-tenant API, roles, reports and exports | 56 |
| Integrations: subscription billing, single sign-on, email | 22 |
| QA: test plan and regression | 22 |
| Release and monitoring | 7 |
| Total | 201 hours, a budget of $6,600-13,600, about 5 weeks |
The same run takes five guesses for the business side: $99 a month per customer, an 80% margin, 24 months as a customer, $600 to win one and 15 new customers a month. With those guesses, 8 customers pay for the build and the build is paid back in month 16. Change any guess and the math updates. It’s a planning range, not a fixed quote.
You can run your idea through our project estimate to get the same breakdown for your product. Once the build starts, the team switches to points and velocity for its sprint plans.
In our dedicated development teams a Scrum Master runs this process, and you see the result at every sprint review. For the wider picture of why estimates miss, read about agile project estimation challenges.
A team estimation technique. Each developer picks a card with a number in secret, everyone reveals at once, the highest and lowest voters explain their reasons, and the team votes again until the numbers are close. The numbers are usually story points.
A common deck has 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. It’s a modified Fibonacci sequence: the gaps grow with the numbers, because big items are harder to size precisely.
The developers who will build and test the work vote. The product owner explains the stories and answers questions, and a Scrum Master or another facilitator runs the session.
Usually one to three per item. If the votes still don’t come together, take the higher number or split the story, following a rule the team agreed on before the session.
Not on its own. A 2026 study found that language models can predict story points better than deep learning models trained on a project’s own data, but they don’t know your team, your code or your risks. Use an AI estimate as a starting point and let the team agree with it or argue against it.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.