What Is Planning Poker? A Practical Guide to Agile Estimation
Planning or Scrum Poker in One Paragraph: What It Is and How It Works
Planning poker, also called Scrum Poker, is a group estimation technique used to assess the size and complexity of work items. The core mechanic is simple: each team member estimates independently, then everyone reveals their number at the same moment, which prevents groupthink and surfaces differing assumptions before work begins.
The method is most widely used in agile software teams, and run online, but the problem it solves is not unique to software. In this article, which can be treated as a beginner’s guide to understanding planning poker, we cover how planning poker works online and offline, when it’s worth using, and where it applies, including examples from product or development teams, marketing, healthcare, and small business operations.
Why Estimates Go Wrong, and What Planning Poker Does About It
Estimates are hard to get right, and not because people are bad at their jobs. A developer looks at a backlog item and sees a data model problem. A QA engineer sees three edge cases that will need separate test scenarios. A designer sees a dependency on brand assets that don’t exist yet. Everyone nods in the meeting, and three completely different numbers are quietly forming in three different heads.
Research consistently shows that estimates improve when they bring together multiple expert opinions from a cross-functional team. But bringing people together isn’t enough on its own. The structure of the conversation matters. When one person says a number first, everyone else anchors to it. When a senior voice states an estimate confidently, junior team members rarely push back. The group converges on a number, though not necessarily on shared understanding.
Planning poker is a structured estimation technique designed to prevent exactly this. It was built for software teams, and that’s still where it’s most commonly used. But the problem it solves isn’t a software problem: it’s a group dynamics problem. The method works equally well across departments, including marketing, operations, HR, and others, and scales to organizations of any size, from small businesses to large corporations. The industry doesn’t matter much either: teams in healthcare, education, professional services, local offline businesses, and retail are just a few examples of where it can be applied successfully, for the same reason software teams use it.
This guide covers how it works, where it applies, how to implement planning poker effectively, and how to avoid the ways it commonly goes wrong.
Where planning poker came from
In 2002, James Grenning created planning poker as a response to the estimation processes of the day, which he felt took too much time without solving the core problem. His original goal was straightforward: stop people who agree from dominating the process, and give everyone a genuine voice. Mike Cohn, co-founder of the Agile Alliance and Scrum Alliance, later popularized the technique in his 2005 book Agile Estimating and Planning.
Planning poker became a standard practice in Scrum and other agile frameworks quickly after that, and most of its vocabulary reflects those origins. According to the Journal of Computer Science and Technology, over 84% of agile teams use planning poker to estimate story points.
According to the International Scrum Institute, a study published in the Journal of Systems and Software found that structured estimation techniques like planning poker can improve accuracy by up to 40%.
Its spread beyond software teams, though, wasn’t accidental. The mechanics of the method — independent estimates, simultaneous reveal, discussion of outliers — work on any work that involves uncertainty and multiple people who may see the same task differently. A hospital department estimating a process change and a marketing team sizing a campaign launch face structurally similar problems to a dev team estimating a feature. The method travels well.
What planning poker actually does
The name is intentionally informal, but what happens beneath the surface is substantive.
It separates thinking from discussing. Each person forms an estimate independently before seeing what anyone else thinks.
Hiding figures this way avoids anchoring bias: when someone states a number first, that number sets an invisible reference point that pulls everyone else toward it. The simultaneous reveal removes that pull entirely.
It gives every voice equal weight. In traditional estimation meetings, once someone says a number out loud, the rest of the team tends to align around small variations, especially when that number comes from a senior person. Planning poker removes that dynamic structurally. Everyone plays a card at the same moment.
It turns disagreement into a signal. When estimates spread widely, the spread itself is the finding. It usually means team members are picturing different scope, different implementation approaches, or different definitions of “done.”
Practitioners who use planning poker regularly note that the most valuable sessions are often the ones where estimates diverge most significantly, because the divergence surfaces assumptions that needed to surface before work started.
And it improves accuracy over time. Studies have found planning poker estimates to be statistically more accurate than individual estimates for the same tasks. Part of the reason: being asked to justify an estimate has been shown to produce numbers that better account for missing information, which matters in environments where work items are often intentionally vague at the point of estimation.
What are the rules of planning poker? the step-by-step basic flow
Planning poker can run synchronously during a meeting or with async preparation beforehand, which is particularly useful for distributed and remote teams.
What you estimate in: planning poker cards and scales
Planning poker doesn’t require any particular measurement unit. Teams use it with story points, ideal days, hours, and T-shirt sizes. The scale matters less than the consistency: everyone on the team should understand what each value represents, and estimates across sessions should be comparable.
Many teams use a Fibonacci-style sequence because the gaps between values grow as the numbers grow, which matches the reality that larger work carries more uncertainty than smaller work. The reason for Fibonacci specifically, rather than simply doubling each value, is that estimating a task as exactly twice another is misleadingly precise. A task that seems roughly twice as large as a “5” has to land at either 8 (slightly less than double) or 13 (slightly more), which forces a cleaner, more honest decision.
A note on story points: story points express relative size rather than time. A point value typically represents a combination of effort, complexity, uncertainty, and dependencies. You don’t have to use story points to use planning poker. The method works with any shared scale.
Planning poker in practice: four examples
Planning poker was built for software teams. The first example reflects that context. The next three show how the same mechanics apply in very different environments and produce the same kind of useful outcome.
1. Product development team: adding a feature to an existing product
A product team is planning a sprint. One backlog item: “Allow users to save and reuse custom report templates.”
Estimates come in: 3, 5, 5, 13, 8.
The 13 stands out. The developer who chose it explains: the feature looks simple from the outside, but the current report engine has no concept of “templates” at all. A proper implementation needs a new data model, a storage layer, and UI for naming and managing saved templates. What looks like one feature is closer to three.
The person who estimated 3 assumed templates would be saved filter presets — a simpler implementation they’d done before in a different codebase.
After the discussion, the team re-estimates: 8, 8, 8, 13, 8. They record 8 and add a note to the ticket: the data model architecture decision needs to be made before development starts.
The final number matters less than what the round surfaced: two completely different visions of the same feature, found in planning rather than midway through a sprint.
2. Marketing: planning a campaign launch
A growth team is sizing work for an upcoming launch. Unlike many agile teams, they estimate in hours using the Fibonacci scale (1, 2, 3, 5, 8, 13, 21) — it fits how they plan capacity and report to stakeholders. One item: “Create landing page and supporting ad set for the new pricing tier.”
Estimates: 5, 5, 13, 8, 8 hours.
The 13 comes from the designer, who points out that the landing page needs new visual assets. Existing brand guidelines don’t cover the visual direction for this tier, and stakeholder sign-off typically requires two rounds of review from people with limited availability.
The 5 came from the content lead, who was thinking about copy only — a few hundred words, already partially drafted.
This is a common pattern in marketing estimation: different roles picture different slices of the same deliverable. The team splits the item into two: “Copy and structure” at 5 hours, “Design and assets” at 13. The split also clarifies who owns what.
3. Hospital operations: updating a patient intake process
A hospital department is working to improve its intake process. One item: “Update triage checklist and brief staff on changes.”
Estimates: 1, 2, 8, 3, 2.
The 8 comes from the shift supervisor. Briefing staff in practice means coordinating across three shifts, not all of whom can attend a single session. The change involves a compliance-related form requiring sign-off from another department. And the last time something similar was rolled out, two staff members needed individual follow-ups before the change actually held.
The 1 came from an administrator thinking purely about the document update: revise the file in the shared folder, done.
The conversation surfaces a scope question the item had never made explicit: does this mean publishing the updated document, or full staff adoption? The team decides it means adoption, re-estimates at 5, and adds a sub-task for compliance sign-off. Without the spread, that distinction would have appeared during implementation.
4. Small local business: preparing a second location to open
A restaurant group is getting ready to open a second café. One item: “Hire and onboard front-of-house staff.”
Estimates: 2, 3, 13, 5, 5.
The 13 comes from the operations manager, who has done this before. Posting and screening alone takes two to three weeks minimum. The training program isn’t documented yet. Onboarding needs to be sequenced before equipment delivery. And “ready to serve” means something specific: not just hired, but trained on the POS system, familiar with the menu, and capable of handling a rush.
The 2 came from a team member thinking about the job posting: write it, put it up, done.
The discussion makes clear that “hire and onboard” was carrying four separate workstreams inside one line item. The team breaks it into job posting and screening, training program documentation, onboarding scheduling, and operational readiness sign-off. The opening timeline shifts by two weeks, but before commitments were made externally, not after.
Do you ultimately need special software online to run planning poker?
No. The method works fine without any dedicated tools, and it’s worth understanding the low-tech version before evaluating software options.
The physical setup is simple: write each value in your chosen scale on separate slips of paper (one set per person). For a standard Fibonacci scale, that can be: 1, 2, 3, 5, 8, 13, 21. Each person holds their set face-down, selects one privately, and flips on a count of three. Record the results, discuss if needed, and move on.
For remote teams, a shared spreadsheet or a messaging channel with a “submit then reveal” protocol can work at small scale. Some teams use freeware estimation apps that do nothing more than collect and display cards simultaneously.
Where dedicated planning poker software adds real value is in friction reduction and process consistency: private submission, simultaneous reveal, async estimation before the session, and a persistent record of estimates tied to backlog items. In our view, all of these are worth having, and they’re exactly what doBoard is built around, as we’ll show in one of the next sections. For occasional use with a co-located team, though, the paper version is completely functional.
What planning poker is not good for
Practitioners who’ve used planning poker extensively note that it gets a bad reputation mostly from misuse: sessions where the team spent 45 minutes debating whether something is a 3 or a 5, or rooms where everyone quietly followed the tech lead’s card to avoid friction. The method works when the conditions support it. When they don’t, it creates a different set of problems.
The right question isn’t whether software is necessary but whether the time your team spends on logistics during sessions has a cost. If it does, that’s where tools help.
Common mistakes when implementing planning poker
Running planning poker with doBoard
doBoard has planning poker built directly into the task view.
Estimates can be done for each task, which means team members can review the task description, ask questions in the comments, and submit their estimate asynchronously before the session. There’s no separate tool to open, no voting links to share.
When everyone has estimated, the scrum master, project lead, or whoever created the task opens the results. Until that moment, each participant sees only their own vote. The team uses the Fibonacci scale (1, 2, 3, 5, 8, 13, 21), and can agree internally whether estimates represent hours or story points, depending on how the team works.
This way, your planning meetings run more productively, estimations are tied to the task context that any team member can review at any time, and you always have a full history of estimates available for further refinement.
How to Run Planning Poker in doBoard: a Real-World Example
The walkthrough below is based on a real example of planning poker run in doBoard. It’s not a perfect session, and that’s the point. Real estimation looks like this: some things surface mid-session, and the outcome is still better than whatever would have happened without a structured process.
Step 1: Add the task and describe it
Jane, the product owner, adds a task to the backlog: “Allow users to save and reuse custom report templates.” She includes a brief description: “Enable users to create and store personalized report presets for future use.”
The Fibonacci scale (1, 2, 3, 5, 8, 13, 21) sits directly inside the task. Team members submit their estimate privately at any point before the session.
Step 2: The team estimates asynchronously
Daniel opens the task and selects 8h. Peter does the same. Each sees only their own estimate; everyone else’s stays hidden until results are opened.
Emma opens the task but doesn’t estimate right away. The description feels too broad, so she leaves a comment asking for clarification. Jane replies and suggests discussing it on the planning call. The question is on record before the meeting starts.
Step 3: Open the results at the meeting
Jane opens the results: Daniel, Peter, and Emma all estimated 8. Jane estimated 3.
Jane had assumed the feature could be built on top of existing saved-filter functionality. The rest of the team had independently assumed a fuller implementation: a new data model, a storage layer, and UI for managing saved templates.
Two completely different features under the same task title, visible only because everyone estimated independently.
Step 4: Discuss, then re-estimate
The team talks it through. Jane acknowledges the simpler path would produce a feature, but not the right one.
They align on the fuller scope, and Jane opens a new round of voting. Estimates come in at 8h and 13h — a tight spread reflecting shared understanding.
What could have gone better
Jane’s description left scope genuinely ambiguous. More detail upfront would have reduced that ambiguity before anyone estimated. When task owners anticipate the obvious scope questions in the description, first-round results tend to be more accurate and re-votes become the exception rather than the routine.
Why the async setup matters
This works because estimates happen before the meeting. By the time the team gathered, everyone had read the task and formed an independent view. The meeting was used for what it’s genuinely good at: resolving real disagreement. Without the async layer, people would have read the task for the first time in the session, heard Emma’s question asked out loud, and formed opinions while listening to each other, which brings back exactly the anchoring planning poker is designed to prevent.
Want to learn more about how planning poker works in doBoard?
Ready to try it with your team?
Setup takes a few minutes. Free 7-day trial, then $5 per month for the whole team for all functionality, unlimited users and projects included.
FAQ
Planning poker is a group estimation technique used in agile teams to assess the size and complexity of work items. Each team member estimates independently, then everyone reveals their number at the same moment. When estimates differ significantly, the team discusses the reasons before re-estimating. The simultaneous reveal prevents anchoring and gives every voice equal weight, regardless of seniority.
No. Planning poker is most commonly associated with Scrum and agile frameworks, but the core mechanics apply to any work with meaningful uncertainty and multiple people who may see the same task differently. Marketing, operations, HR, and other non-technical teams use it regularly. The examples in this article reflect that range.
A few things make the biggest difference: share task descriptions before the session so people arrive with context, keep the task owner in the clarifier role rather than the estimator role, and treat a wide spread as useful information rather than a problem to close quickly. Sessions work best when kept under 90 minutes, and items that can’t converge after two rounds usually need more definition rather than more voting.
The most common ones: sessions run long when items are too vague or too large; estimates lose value when team members don’t feel safe disagreeing with senior colleagues; and teams sometimes mistake forced consensus for alignment. The method works well when items are reasonably defined and the team culture supports honest disagreement.
It depends on how your team works. For co-located teams estimating occasionally, paper cards or a simple free app are enough. For remote or distributed teams, a dedicated planning poker tool adds real value: private submission, simultaneous reveal, async voting tied to task context, and a history of estimates. doBoard includes planning poker built directly into the task view, so estimation happens where the work already lives.
Teams use a range of options, from physical cards and freeware apps to purpose-built agile planning poker software and project management tools (like doBoard) with estimation features built in. The trend for distributed teams is toward async-first tools where estimates can be submitted before the meeting rather than only during it.
Yes. Remote teams use online planning poker tools where everyone submits an estimate privately before a group reveal. A hybrid model works well for distributed teams: members read items and estimate asynchronously before the session, then synchronous time is used only to discuss items with significant spread.
Use whatever your team can estimate consistently. Story points work well for agile planning poker sessions where teams want to avoid false precision in time estimates. Hours work when the team has reliable calibration data. T-shirt sizes work for non-technical teams or early roadmap sizing. The specific scale matters less than using the same one consistently so estimates stay comparable over time.
The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is used because the gaps between values grow as the numbers get larger — which reflects how estimation actually works. Small tasks can be distinguished with reasonable precision, but larger tasks carry more uncertainty, and pretending otherwise leads to false precision. A task that feels roughly twice as large as an “8” has to be called either 13 or 21, which forces a cleaner, more honest decision than a scale that lets you split the difference at 15 or 16. The widening steps also make it easier to spot when a task is too large to estimate reliably and should be broken down first.
Leave a Comment