How to Run Planning Poker: Your First Session, Step by Step

Your team has agreed to try planning poker. The meeting is booked and the backlog has stories to size. Then someone asks the first question: "What does a three mean?" Nobody knows, because the team has nothing to compare against yet.

Many first sessions stall at this point. People argue about the deck, nobody is sure who should vote, and the first story takes half the meeting. Planning poker is not the problem. The team skipped some setup choices, and now it must make them in the middle of a round.

This guide shows how to run planning poker with a first-session routine in five moves. You pick a deck, set a baseline with two reference stories, explain secret votes and the shared reveal, agree what counts as consensus, and decide who speaks first on a split. Each move is short and removes a common cause of a slow or confusing first round.

The routine is for every role on the team. Scrum masters and delivery leads get a setup plan. Product owners and engineers learn their part in a round and why the rules exist. A first planning poker session works when your team agrees on the deck, the baseline, the roles and the rules before the first vote.

How to run planning poker: pick a deck and set roles first

Make three choices before anyone sees a card: the deck, the roles and the stories. A new team often skips these choices and then makes them during a round. That costs time and confuses people who are new to estimation.

Choose one deck and keep it

A planning poker deck is the set of values people can vote with. Common decks are Fibonacci-style numbers (1, 2, 3, 5, 8, 13), a modified Fibonacci set with larger jumps at the top, T-shirt sizes (XS, S, M, L, XL) and powers of 2. Each card shows relative size, not hours. A 5 is bigger than a 2, but it is not a promise of five days.

Fewer cards mean fewer choices. In his post on reference stories and story points, agile coach Bob Galen explains why he prefers small decks: "One of the reasons I like minimal story point options (for example T-shirt sizes over Fibonacci) is the reduced number of choices". He connects fewer choices with fewer reference stories. For a first session, that is a good trade: your team has less to learn and fewer examples to agree on.

Pick one deck and keep it for many sprints. If you change decks often, old estimates become harder to compare with new ones. If your team already thinks in numbers, a Fibonacci-style deck is a good choice. If your team is new to estimation, T-shirt sizes can feel less like a promise of time.

Say who estimates and who clarifies

Planning poker works best when each person knows their job in the round. Agree on the roles out loud at the start of the session:

• Engineers vote. The people who build and test the work give the estimates. They know the code, the tests and the risks.
• The product owner answers questions. The product owner explains the story, the acceptance criteria and the reason for the work. If your team decides that the product owner also votes, say so before the first round.
• The scrum master facilitates. The facilitator reads the story, keeps the rules, calls the reveal and keeps time. A delivery lead can also do this job.

Write the roles where everyone can see them. Then nobody has to guess whether a comment is a vote, a question or an answer.

Bring stories that are ready

An estimate on a vague story is only a guess. Before the session, check each story. Does it have clear acceptance criteria, known dependencies and enough context to discuss? If not, send it back to refinement. A backlog refinement meeting that ends on time is the right place to make stories ready before estimation.

For a first session, bring 8 to 10 ready stories. That is enough to practise the routine without making the meeting too long. If you finish early, end the meeting early.

Setup checklist: One deck, chosen and announced. One facilitator. One product owner on call for questions. 8 to 10 stories that are ready.

Set a baseline with two reference stories

Relative estimation compares a new story with stories that you already know. In a first session, your team has nothing to compare with. Solve this before the first vote: agree on a baseline of two stories.

Pick the baseline by discussion, not by voting

Mike Cohn of Mountain Goat Software explains how a new team can establish its baseline: "They do this without playing Planning Poker. They do it just through discussion." Ideally, the team identifies a two-point story and a five-point story. He avoids a one-point start because it leaves no room for smaller items without fractions. Two baseline values also let even the first stories be compared with two other items.

The baseline is the starting point for all later votes, so a vote cannot produce it. In practice, the facilitator asks the team to look at finished work and talk until they agree. Nobody shows a card during this step.

Why a pair works better than one story

A pair gives you a smaller story and a larger story for every comparison. Suppose a new story feels bigger than your two and smaller than your five. Then a three is a good candidate. If it feels bigger than your five, the team should talk about how much bigger.

The same idea applies to a T-shirt deck. Pick one story that the team agrees is a small (S) and one that is a medium (M). Then compare new stories against both.

Keep the reference set small

Bob Galen's post, linked above, defines the term: "A reference story is a user story that is mined from our existing product backlogs. It’s been implemented and delivered in a sprint." He also gives a clear warning: "But please don’t create too many of them. They lose their effectiveness and simplicity if you have tens of them posted all over the walls."

For your first session, two reference stories are enough. Choose stories that your team agrees were sized about right after delivery. If your team has no delivered stories yet, agree on the pair by discussing work that everyone understands well. Replace them with delivered stories when you have some.

Exercise: choose your pair in ten minutes

1. List finished stories. List 5 finished stories on the team board. Use stories that most people worked on or know well.
2. Recap each one. For each story, the product owner says briefly what it included. The engineers say how the work went.
3. Pick the pair. Pick a small story and a medium story. On a number deck, these become your 2 and your 5. On a T-shirt deck, they become your S and your M.
4. Write it down. Write both stories on the board. Add one line for each that says why it has that size.

If the team cannot agree in ten minutes, take the two stories with the least debate and continue. Do not add more reference stories until the team finds a real gap.

Explain the round: secret votes and a shared reveal

Before the first real vote, walk through one full round and say each step out loud. People who have never played planning poker should know what happens and what they must do.

The round, step by step

1. Read the story. The facilitator or the product owner reads the story and its acceptance criteria.
2. Ask questions. Engineers ask about scope, edge cases and dependencies. The product owner answers. Nobody says a number.
3. Vote in private. Each voter picks one card and keeps it hidden. Compare the story with your two reference stories before you choose.
4. Reveal together. Everyone shows their card at the same time.
5. Accept or discuss. If the votes agree, record the estimate and move to the next story. If they split, use the rules from the next section.

Protect the shared reveal

Anchoring happens when people hear a number first and then move their own estimate towards it. A senior engineer who says "this is easy, maybe a two" can pull the whole team towards that value. The other voters may never say what they think.

A guide to common planning poker mistakes from Scrum Poker Online says the simultaneous reveal is what prevents anchoring. Its advice is direct: "Enforce the simultaneous reveal as a non-negotiable rule." In your first session, make this rule clear and stop anyone who says a number early.

For each role, the rule means this:

• Engineers: Form your own view before the reveal. If you are not sure, vote anyway and explain your reason after the reveal.
• Product owner: Answer questions about what the story needs. Do not hint at how big you think it is.
• Facilitator: Stop any talk about numbers before the reveal. Then call the reveal clearly, so that everyone shows their card together.

Run one practice round

The same Scrum Poker Online guide recommends a practice session with well-understood stories from previous sprints, so that new members can calibrate against the team's norms. Before you estimate new work, play one round on an old story that everyone knows.

After the reveal, check the result against your baseline. Does the old story fall between your 2 and your 5, or above or below them, in a way that the team agrees with? If the votes are far apart, talk about why. This is calibration: the team learns what each value means before the votes start to matter.

Running the round online

A remote or hybrid team needs a way to keep votes secret until a shared reveal. TinyTroop is free online planning poker for this kind of round: a facilitator shares one link, and guests join with a display name only, with no account. You can choose a Fibonacci, modified Fibonacci, T-shirt, powers of 2 or custom deck. Votes stay secret until the reveal, and the reveal shows the average, the median, the spread and the consensus.

A product owner who does not vote can join as a spectator and watch without voting. The facilitator can hand the facilitator role to someone else. When votes split, the tool names the outlier votes, so you know whom to hear first. The storybook look and the mascots also help keep a first session light.

Agree what consensus means and who speaks first on a split

The end of a round needs rules as much as the vote does. Without them, a split can become a long debate. Or the team takes the average and moves on, and nobody learns why the votes were different. Agree on three rules before the first vote, and add a time-box.

Rule 1: Define consensus

Decide what counts as agreement. Some teams need every vote on the same card. Others accept votes on two neighbouring cards, and then the team chooses one of them, for example the higher value. Both options can work. Choose one and write it down.

Consensus does not mean that everyone is fully happy. It means that everyone can accept the value and the team can continue.

Rule 2: Cap the re-votes

Decide how many times the team can vote again on one story. For a first session, two re-votes is a reasonable starting cap. After the cap, take one clear action that you agreed in advance. For example, send the story back to refinement, or split it into smaller stories later.

Without a cap, one hard story can use up the whole session. With a cap, the team knows when to stop and what happens next.

Rule 3: Decide who speaks first on a split

When votes split, the order of speakers matters. A common choice is to ask the highest and lowest voters to speak first. An outlier may have seen a risk, a dependency or a shortcut that others missed. If the most senior person speaks first, the outliers may not speak at all.

Let each outlier explain without interruption. Then the others can add points or ask questions. Then vote again.

Time-box each story

The Scrum Poker Online guide gives a clear range: "Use a time-box — three to five minutes per story — to keep discussions productive without cutting them short." The facilitator keeps time. When the time ends, the facilitator applies Rule 2.

Exercise: write your three ground rules

Write three ground rules on the team board before the first vote. Here is an example that you can change:

• Consensus: All votes on one card, or on two neighbouring cards. If the votes are on two cards, we take the higher one.
• Re-votes: Two at most. After that, the story goes back to refinement.
• Split: The highest and lowest voters speak first, one minute each.

These rules are only a starting point for a first session. For a fuller routine, read our guide on how to hear the outliers when planning poker votes split.

Your first session, in five moves

The full routine for your first session:

1. Pick a deck and set the roles: engineers vote, the product owner clarifies, the scrum master facilitates.
2. Set a baseline by discussion, with two reference stories, such as a 2 and a 5.
3. Explain the round: secret votes and a shared reveal, plus one practice round on a known story.
4. Agree on consensus and the re-vote cap.
5. Decide who speaks first on a split, and time-box each story.

Do the setup before the first vote. Put the deck, the two reference stories, the roles and the three ground rules on one board, and read them aloud at the start. After that, your team only needs to vote, reveal and talk.

When your board is ready, open a room, share the link with your team and play your practice round on a story that everyone knows. Start a free room.