How to run a planning poker session, step by step

To run a planning poker session, prepare a short list of refined backlog items and two or three reference stories, then estimate each item in rounds. The product owner explains the item, the team asks questions, everyone chooses a card in private and the cards are revealed together. The highest and lowest voters explain their thinking, the team votes again, and once the cards agree (or nearly agree) you record the estimate and move on.

The rules of how to play planning poker fit on an index card, but the details decide whether a session takes 40 focused minutes or two draining hours. This guide follows a session in the order a facilitator meets it: preparation, each round, disagreement, re-estimating, splitting, closing, a sample agenda and introducing the technique to a new team. If you are new to the technique itself, start with what is planning poker?

Before the session: prepare the backlog, references and roles

Most sessions that drag were lost before they started, usually because the items were not ready. A little preparation saves far more time in the room.

Get the backlog ready

The product owner chooses the items in priority order and makes sure each one has a clear goal and acceptance criteria. Bring a little more than you expect to finish: around 8 to 12 items for an hour. Share the list a day ahead so people can read the items and raise obvious questions early. If your team has a Definition of Ready, use it as the checklist.

A quick test for each item: could a developer explain to a colleague what “done” looks like? If not, it needs more refinement before it is worth estimating.

Pick two or three reference stories

Reference stories are finished items the team remembers well, with agreed sizes. They give every vote something concrete to compare against. Choose a small, a medium and a large one, for example:

• 2 points: “Show the customer’s last login date on the admin user page.”
• 5 points: “Let customers reorder from their order history.”
• 13 points: “Add two-factor authentication with an authenticator app.”

Keep them visible during the session, on a shared screen or a printed card. How to set a baseline with reference stories covers choosing and refreshing them.

Set a timebox

Book 45 to 60 minutes. Longer sessions lose focus, and the estimates made at the end of a two-hour meeting rarely get the care the first ones did. Inside the session, agree a soft limit per item, around five minutes, and one firm rule: if two rounds of voting do not settle an item, it leaves the room for splitting or research.

Agree the roles

• Facilitator. Runs the rounds, keeps time and makes sure the extremes are heard. Often the Scrum master; many online tools call this role the moderator.
• Product owner. Explains each item, answers questions and decides on scope trade-offs, but does not vote. The 2017 Scrum Guide was explicit that “the people who will perform the work make the final estimate.”
• Estimators. Everyone who will build and test the work, including testers and designers.
• Observers. Stakeholders or new joiners who watch without voting.

Set up the cards

Choose the deck before the session, not during it. Modified Fibonacci is a common default, and planning poker cards and decks explained compares the options. If anyone will join remotely, have everyone vote in the same online tool, including the people sitting together, so all the votes are revealed at the same moment.

How to run each round

Every round follows the same rhythm. Once the team knows it, a round on a familiar item takes under a minute.

1. Introduce the item. The product owner reads the title, the goal and the acceptance criteria. Keep it to a minute or two; the detail comes out in questions.
2. Ask clarifying questions. Questions about behaviour and scope are welcome (“Does this include the mobile app?”). Size words are not: “this looks quick” is an anchor. Two or three minutes is usually plenty.
3. Vote in private. Remind people to size the whole job, including testing, review and release, not just the coding. Nobody shows their card early or comments on it.
4. Reveal together. With physical cards, count down and flip. Online, the moderator reveals once everyone has voted.
5. Read the spread. If all the cards match, or sit on two neighbouring values, settle it quickly. If they are far apart, move to discussion.
6. Hear the extremes. Ask the highest and lowest voters what they were picturing, then open it up briefly to anyone with something new to add.
7. Vote again, then record. Re-vote straight after the discussion. When the cards converge, write the estimate and any key assumption on the item and move on.

One facilitator habit makes a big difference: ask about the work, not the number. “What would we need to build for this to be a 13?” gets a better answer than “Why so high?”, which can sound like an accusation.

Handling disagreement and outliers

Disagreement is the point of the exercise: it shows where the team’s understanding differs. The shape of the spread tells you what kind of conversation you need.

Agree a tie-break rule in advance

Teams can lose a surprising amount of time choosing between neighbouring cards. Agree a rule once and stick to it: for example, after the second round, take the higher of two neighbouring values, or the most common vote. James Grenning’s original 2002 paper was relaxed about it: if the team could not agree, it could defer the story, split it or take the low estimate, because “It is only one story out of many.”

Don’t average

Averaging looks fair but throws away the most useful information. If the cards are 3, 5, 5 and 20, the mean is about 8, a number nobody chose, and the 20 may be warning you about something real. Mike Cohn, who popularised planning poker, recommends another round instead and, if a team truly must average, using the median rather than the mean. His other suggestion works well at an impasse: propose a reasonable number and ask whether everyone can support it, rather than whether everyone thinks it is perfect.

Look after the outlier

The person who played the odd card has just disagreed with the whole team in public. Thank them for it. If they spotted a real problem, say so; if they misunderstood the item, the correction was cheap. Either way, the next time they see a risk, they will play the card that shows it.

When to re-estimate

Re-voting within a round is normal, and one to three rounds is usually enough. If you are on a third round and the cards are still far apart, more voting will not help: the problem is the item, not the estimators.

Re-estimating an item in a later session is different. Do it when:

• the scope has changed materially, such as a new acceptance criterion or a different integration;
• the team has learned something important, for example from a spike;
• the item has sat in the backlog for months and the code around it has changed.

Avoid re-estimating finished work just because it turned out bigger or smaller than expected. Your velocity and forecasts were built on the original estimates, so changing them after the fact makes your history less useful. Discuss the surprise in the retrospective instead and, if it was a big one, consider adding the item as a reference story at the size it really turned out to be.

When to stop, split or park an item

Take an item out of the round when you see any of these signs:

• the cards are still far apart after two rounds;
• most votes are on your largest values, such as 20, 40, 100 or ∞;
• several people play ?;
• the discussion has turned into designing the solution;
• the one person who knows that part of the system is missing.

Then choose one of four moves:

1. Split it. Break the item into smaller pieces that each deliver something useful, and estimate those. “Customers can pay invoices by bank transfer” might become “Show bank details on the invoice”, “Mark an invoice as paid manually” and “Match incoming payments automatically”. How to split user stories has the patterns.
2. Spike it. Create a short, timeboxed piece of research to answer the open question, and estimate the item afterwards.
3. Park it. Write down the question, give it an owner and a date, and bring the item back to the next session.
4. Accept a rough number. If the item must be planned now, take the higher card, mark the estimate as provisional and note the main risk beside it.

Many teams also set a ceiling: anything above 13, or whatever value the team chooses, must be split before it can enter a sprint. That keeps sprint items small enough to finish and turns the big cards into a signal rather than an estimate.

Closing the session and recording estimates

Record each estimate in your backlog tool as soon as the round ends, not from memory afterwards. Next to the number, add anything the team assumed and any follow-up actions. A useful record looks like this:

Then use the last five minutes to:

• read back the items estimated, split, spiked or parked, with an owner for each open question;
• check whether you now have enough ready work for the next sprint or two, and book more refinement if not;
• ask one quick question about the session itself: “What should we do differently next time?”

On planningpoker.org After the reveal, the SprintPoker room shows the average, median, most common vote, range and a distribution chart. The moderator picks the final estimate and presses Save & Next, or starts a new round with Re-estimate. With a free Laya account and a Jira connection in your workspace, Save & Next can write the estimate back to Jira, by default to the board’s own estimation field.

A sample 60-minute planning poker agenda

This agenda suits a team of five to eight estimators with a refined backlog. Stretch or shrink the middle block to fit the number of items.

Tip If you need more than an hour of estimating, run two shorter sessions in the week rather than one long one. Tired teams stop discussing and start agreeing with whatever gets them out of the room fastest.

How to introduce planning poker to a new team

Teams new to planning poker often worry about two things: that it will waste time, and that the numbers will be used against them. A good introduction answers both in the first session.

1. Explain the why in five minutes. Private votes avoid anchoring, everyone’s view counts, and discussing the extremes is where hidden work comes out. The number is almost a by-product.
2. Agree what the estimates are for. Planning the next sprints and spotting items that need splitting; not measuring individuals or comparing teams. Say it out loud, and ask whoever manages the team to say it too.
3. Choose a simple scale. Modified Fibonacci suits most teams. If numbers feel loaded, start with T-shirt sizes for a few sprints and move to points later.
4. Play a practice round. Estimate household jobs against one reference: if mowing the lawn is a 3, how big is painting the spare room, assembling a flat-pack wardrobe or clearing out the garage? The disagreements (“Whose garage?”) show in five minutes why assumptions matter.
5. Build your first reference stories. Take a handful of recently finished items, sort them from smallest to largest and agree their sizes.
6. Keep the first real session short. Estimate five or six items in 30 to 45 minutes. Expect it to feel slow; it speeds up as shared reference points build.
7. Review after three sprints. In a retrospective, ask whether estimating is helping you plan. Adjust the deck, the timebox or the preparation, but keep the private vote.

The same objections tend to come up in the first few sessions. “This is just hours with extra steps” is answered by comparing items with reference stories instead of the calendar. “We don’t have time for this” is answered by a strict timebox and a tidy backlog. “People will just copy the senior developer” is exactly what the private vote prevents. Once the basics are in place, these planning poker facilitation tips help sessions get faster and fairer.