Planning Poker: How It Works and Why Teams Use It

Planning poker exists to stop the first number said aloud in an estimating meeting from becoming the team’s answer. Each estimator chooses a card in private, everyone turns their card over at the same moment, and the people holding the highest and lowest cards explain their thinking before the team plays again. James Grenning, a software consultant, described and named the game in 2002.¹ Mike Cohn then spread it through his book Agile Estimating and Planning, published in 2005.² The research behind it is thin but useful: in a 2008 study of one software project, planning poker estimates came out less optimistic than the average of the same people’s private guesses.³

To play a round of planning poker:

1. Present the item
2. Estimate privately
3. Reveal together
4. Discuss the extremes
5. Re-vote

Sizing work is a routine part of project management, and agile teams often reach for planning poker when the pieces are small but their shape is still uncertain.

How planning poker works, step by step

Every backlog item goes through the same five moves, and only two of them are unusual: each person commits to a number alone, and all the numbers appear at once. Grenning’s original 2002 paper describes exactly this loop, with each programmer writing an estimate on a note card.¹

1. Present the item

The Product Owner, or whoever speaks for the customer, reads out one item, usually a user story. The team asks questions until it understands what done means. Nobody mentions a size yet, because a number dropped into this conversation would sit in everyone’s head when they choose a card.

2. Estimate privately

Each estimator picks the card that matches their own sense of the work and lays it face down. This is the step that makes the game different from a discussion, because every person has to commit to a view before hearing anyone else’s.

3. Reveal together

On a count, everyone turns their card over. If the cards agree, the team records the number and moves straight to the next item.

4. Discuss the extremes

When the cards differ, the people with the highest and lowest cards speak first. Cohn’s guidance explains why: a high card often points to hidden work or risk, and a low card to a simpler design, an existing component or a safe shortcut.⁴

5. Re-vote

With the new information on the table, everyone picks again in private and reveals again. Keep the second round as private as the first; a re-vote taken out loud gives the loudest voice its anchor back.

A round of planning poker, played out

A single round shows why the discussion matters more than the final card. In this illustrative round, a product team estimates one user story with a modified Fibonacci deck, and the gap between the first cards exposes a scope question nobody had asked.

The Product Owner reads the story: “As a returning customer, I want to download all my past invoices in one file, so that I can send them to my accountant.” The team asks two quick questions about file format and then plays.

1. 1First reveal2, 3, 3, 8 and 13
2. 2Lowest explainsa developer: single-invoice download already exists, so this is a loop
3. 3Highest explainsthe tester: invoices from before last year sit in the old billing system
4. 4Scope settledthe Product Owner: accountants only need the current and last tax year
5. 5Second reveal3, 5, 5, 5 and 5; the team records 5

Without the hidden cards, the developer’s quick “it’s basically a loop” might have been the first thing said, and the table would probably have settled near the low end. The tester’s knowledge of the old billing system came out because the card forced a commitment first, and the Product Owner could then cut the work rather than pay for it.

Why the cards stay hidden: anchoring and deference to seniors

The cards stay hidden until everyone has chosen so that neither the first number spoken nor the most senior person’s opinion sets the estimate for everyone else. Wikipedia’s entry names anchoringanchoring: The tendency for an estimate or decision to be pulled toward a number seen beforehand, even an irrelevant one. It is one of the effects that held up when large teams ran the original experiments again.Full entry in the glossary as the bias the reveal avoids.²

Software estimators are not immune to anchoring. In a 2005 Canadian experiment, Jorge Aranda of the University of Toronto gave 23 volunteers, mostly computer science graduate students, the same project documents to estimate; the only difference was one remark from a client manager who admitted having no experience with software projects. People who read a guess of 20 months gave estimates about twice as long, on average, as people who read no guess at all; a guess of 2 months made no clear difference.⁵ Twenty-three people on a paper exercise is a small test, yet a guess from someone with no claim to expertise still moved the estimates.

Seniority adds a second pull. A note on Grenning’s company site says the meeting that led to the game stalled with the two most senior people debating while the others got a virtual nap, and Grenning writes there that the idea came from a quality-management technique of writing ideas down silently, so the most dominant or senior person could not sway the rest.⁶

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

A new tester on a team of experienced developers is the person this protects. Asked aloud after the lead developer has said “this is a small one”, a newcomer may simply nod; asked to commit to a card first, the tester may be the one who remembers that the change touches the payments screen.

1. Said aloud first: the first number heard pulls the other estimates toward it, an effect called anchoring
2. Chosen in private, shown together: the real spread stays visible, and the highest and lowest estimators explain first

The protection ends at the reveal. Cohn notes that a strong personality can still dominate the discussion that follows, and suggests the facilitator ask the high and low estimators to speak first, especially when they are usually quiet.⁴ Senior people help most by keeping their own sizes to themselves until the cards are down.

Is planning poker more accurate? What the studies found

Few published studies have tested planning poker, the ones we found are small, and their results point in different directions. In one Norwegian team, group estimates were less optimistic than the average of private ones and about as accurate as a single expert’s.³ With student teams in Slovenia, estimates grew more optimistic after the group discussion.⁷

The study

Limited evidence

Half the tasks by poker, half by solo experts: one team's project

Researchers introduced planning poker for half the tasks in one software project and left the rest to individual experts. The team’s consensus estimates were less optimistic, and more accurate, than the mean of the same people’s private estimates for the same tasks. Tasks estimated by individual experts reached similar accuracy, and both groups’ typical task was on target. A code analysis linked the extra effort on the planning poker tasks to more complex changes, which the authors suggest may have come from what the group discussion brought to light.³

The authors first reported the project at a 2007 conference.⁸ Their slides from the time describe a small Scrum team of consultants in Norway working in two-week sprints, which is a narrow base for any general claim.⁹ If the authors’ explanation of the extra effort holds, the discussion may have changed what the team built as well as what it predicted.

The second study complicates the picture. Viljan Mahnič and Tomaž Hovelja at the University of Ljubljana in Slovenia had 13 student teams build the same records system from the same user stories. The students’ estimates were over-optimistic, and the authors report that planning poker added to that optimism; a group of experts using the same method produced estimates much closer to the effort spent. The authors conclude that the optimism caused by group discussion fades as the expertise of the estimators grows.⁷

Treat planning poker as a way to find work that one person would miss, and check whether it does that for your team. Before using the numbers in promises to stakeholders, check a few sprints of estimates against the effort the work took.

Why does planning poker use Fibonacci numbers?

Planning poker decks leave out most numbers because bigger estimates are less certain, so the gaps between cards widen as the values grow. A team can tell a one-day job from a two-day job, but not a twenty-day job from a twenty-one-day one, and the widening gaps stop it arguing over differences nobody can judge. Mike Cohn ties this to Weber’s law, the finding that people notice differences in proportion to size, and says each Fibonacci value is roughly 60 percent larger than the one before. His modified series runs 1, 2, 3, 5, 8, 13, 20, 40 and 100: he replaced 21 with 20 because stakeholders read precision into the odd number, then added 40 and 100 for very large items. Until 2007 his teams also tried a doubling deck, and he found no clear evidence that either sequence worked better.¹⁰

Grenning’s original deck made the same point with fewer cards: 1, 2, 3, 5, 7 and 10, plus infinity for a story too big to estimate. Players who wanted a value in a gap could play two cards, though he bet the extra precision would not help much.¹

In Cohn’s guidance the cards usually stand for story points, a relative size rather than hours, though teams can also play in ideal days, and many decks add a question mark and a coffee cup.⁴ Whatever the unit, keep to one deck for a while, so that a 5 means the same thing this month as last.

Who should take part in planning poker?

The people who will do the work hold the cards. The 2020 Scrum Guide makes the Developers who will do the work responsible for sizing backlog items, with the Product Owner helping them understand trade-offs.¹¹

Mike Cohn spells out what that means at the table: everyone whose effort goes into finishing the item estimates, testers, designers and database specialists included. The Product Owner explains and answers questions without estimating. A Scrum Master or coach often facilitates and plays a card only if they also contribute to the work. Stakeholders may sit in when their knowledge helps, but Cohn’s warning is direct: they should not pressure the estimate.⁴

The sizes settled this way feed sprint planning, where the team decides how much fits into the next sprint. When the Product Owner hears a size bigger than expected, the useful answer is a scope trade-off, the same move as in the invoice example, rather than a request for a smaller card.

Keeping sessions short, in a room or on a call

A planning poker session stays short when each item gets a time limit and the team stops playing items it cannot yet estimate. A timer on the table or a countdown in the app, set to a few minutes per item, makes the limit real instead of polite. Grenning reported that once his teams played the game, most stories took about a minute instead of 10 to 30 minutes of debate, with matching cards needing no discussion at all. That was an observation from his own coaching rather than a measured result.¹

Cohn suggests one to three rounds per item is usually enough; more often means the item needs clarifying, splitting or a decision from the Product Owner, so write down the open question and move on. Remote sessions follow the same rules. Cohn recommends a tool that hides every estimate until everyone has chosen, keeping the item on screen during discussion, asking the high and low estimators to speak first, and recording assumptions as they are agreed. He names the two usual failures: people multitasking, and one person talking the team into a number before others have thought it through.⁴

Before the next planning poker session

• Only items the team expects to work on soon are on the list
• Everyone who will do the work has the same deck or app
• No one says a size before the reveal
• Each item has a time limit, and someone will call it
• Highest and lowest estimators speak first, quiet people included
• Items still split after three rounds go back for clarifying

When to skip planning poker

Skip planning poker when nobody will use the number, or when a quicker rough sort is enough. The 2020 Scrum Guide never mentions estimates or any estimating technique; it asks only that backlog items carry a size and leaves the method to the team.¹¹

Grenning himself is wary of overdoing it. In the same note, he still sees estimation as important in many settings, but says he cringes at days-long planning poker meetings and agrees with the No Estimates movement that they waste time.⁶ Cohn draws a similar line: planning poker is usually overkill for distant ideas in a large backlog, where a faster grouping method such as affinity estimation can sort many items first.⁴

Teams that pull work continuously instead of planning fixed sprints, the main difference covered in how Scrum and Kanban compare, should ask what decision each estimate supports. If the answer is none, the conversation may still be worth having, and the card can be dropped.

The bottom line

The value of planning poker is the moment everyone commits to a view before hearing anyone else, and the minute after, when the highest and lowest cards explain. Keep the cards hidden until the reveal, let the people who will do the work hold them, and limit each item to a few rounds. Then compare your estimates with what the work took before you lean on them.