Sprint Poker (Planning Poker): How to Run It and When to Skip It

Sprint poker is a short meeting where everyone votes a number for one backlog item, then talks only about the votes that disagree. Use it when a silent vote will surface hidden assumptions. Skip it when the item is tiny or already understood, or when the time left matters more than a precise point value.

Many teams call the same practice planning poker. Here the name means the short version inside sprint planning, not a workshop to size the whole backlog.

What the vote is for

The useful part is the gap between votes. A quiet "5" next to a quiet "13" usually means two people pictured two different jobs: one saw a config change, the other saw a migration plus a rollback. If the loudest person speaks first, you never find that out.

Story point estimation works because the scale is relative. When you vote, you're saying the item looks like a reference story you already shipped. You aren't promising hours. Keep two or three references where everyone can see them.

The Scrum Guide does not require points or cards. It asks for a sprint that can meet a goal.

How to run sprint poker

Vote only on items you might pull in, in priority order, and stop once the sprint is full. If you size the rest too, a 40-minute meeting turns into two hours.

Deck and reference stories

Use 1, 2, 3, 5, 8, 13, and a "too big" card (20, 40, or ?). The gaps are deliberate. The difference between 12 and 13 is noise, while 8 versus 13 means different jobs.

Pick references before the first vote and reuse them:

• 2: a known change with a clear test, such as a label and a validation rule.
• 5: work in one service, plus a short QA pass.
• 13: cross-team work, a migration, or a rollback path.

If the scale shifts every week, velocity stops meaning anything. Scrum velocity is only useful when "a point" stays stable.

The round

Make the facilitator the person who would otherwise talk the most.

1. The product owner reads the item, the acceptance notes, and any constraints (a date, a dependency, compliance).
2. People ask clarifying questions only. Design comes later.
3. Everyone picks a card privately, then all cards are revealed at once. Apps, fingers, or paper all work, as long as nobody sees a vote early.
4. The highest and lowest voters each get under a minute to describe the work they counted. They aren't there to defend the number.
5. Vote once more. A one-step spread (5 and 8) takes the higher number. A wide spread means you split the item or park it. A third vote rarely helps.

Give each item five minutes and then stop; if it needs more talk than that, it isn't ready. Don't average the votes. Only the people who build and test the work vote, so the product owner doesn't vote on effort. Include design or support when they own part of the item.

A worked example

Item: "Guest users can apply a single promo code. Invalid codes show the reason. Codes cannot stack." Reference: last month's phone field, which was a 3.

Round one comes out 3, 5, 8, 5, 13. The person who voted 3 counted a field and an error string. The 13 added stacking, fraud checks, and a finance export. This sprint only covers one code, so the export becomes its own item. Round two is 5, 5, 5, 8, 5. The team records an 8 so QA covers percent, fixed, and expired codes.

It enters the sprint backlog as an 8, and the whole thing took seven minutes. If someone had just said "it's a 3" out loud, the export would have stayed buried.

Where it sits in the planning meeting

1. State the sprint goal in one sentence before anyone votes.
2. Work out capacity: days off, on-call, carry-over.
3. Vote only on items that could fill the remaining space.
4. Drop anything that doesn't serve the goal, even if the points fit.

A written sprint planning meeting agenda protects time for the goal. Capacity and commitment are covered in the sprint planning guide. If you vote in chat, hide the results until everyone has voted, and write the assumption on the ticket.

When to skip sprint poker

Skip the vote when it won't change a decision.

• Same item, same people as last sprint: copy the points.
• Under an hour and already specified: the vote costs more than the job.
• A bug you can already name: points on "we'll know when we see it" are fiction.
• Still anywhere from 2 to 13 after one question: split the item or learn more first.
• You need a release date: use throughput or cycle time. Cards only find scope that people haven't shared yet.

A quarterly multi-team plan is a different meeting, because most people in the room won't build the pieces. A confidence vote on a shared objective can help there. Cards on a quarter's worth of work won't.

If every item comes out a 5, people re-vote to fit the calendar, or everyone copies the most senior person's card, switch to three options: fits, too big, or unclear. Split anything too big, and treat unclear as not ready.

What the number is allowed to mean

Points compare items inside one team. They aren't a contract or a score, and other teams can't reuse them. Don't turn them into hours in the meeting: something that took six hours last month can take two days if the person who knew the module is away. If finance needs hours, make that a separate estimate.

Velocity is the points a team finishes per sprint, and it only holds for the same team while the scale and roster stay put. For a single week, a count of items is often more honest. A date for a larger batch should come from cycle time and a Monte Carlo-style spread of finished work. "32 points, so two sprints" falls apart when a hidden migration eats the first week.

Falrow keeps those apart. Cycles hold the sprint boundary and roll unfinished work forward only after a review. Insights forecasts from finished tickets. Any tracker with completion dates can do the same.

Mistakes that waste the round

Designing instead of sizing. Write the question down, estimate a small investigation, and move on.

Averaging. A 2 and a 13 need a conversation, and the answer is never 7. Take the higher neighbor or split the item.

Pressure for a smaller number. Pick the number, then state the scope it assumes.

Resetting the scale because velocity looks bad. Switching to T-shirt sizes mid-quarter deletes the history, so if you do it, mark the break.

Praising low cards. It teaches people to hide risk. Have the high voter explain first.

A policy for this week

Add six lines to the sprint planning template:

• Only vote on items that might enter this sprint.
• One re-vote, then split, park, or take the higher number on a one-step gap.
• Write the assumption next to the points.
• No points on a known bug fix.
• No converting points to hours in the meeting.
• Five minutes per item, then move on.

If the tracker forces a number, people type 3 to get past it. Leave the field blank or mark it "not estimated." Once defaults outnumber real votes, skip the vote and spend the time on the goal.

FAQ

Is sprint poker the same as planning poker?

Yes. Both use a private vote, a short talk about the outliers, and one more vote. Sprint poker is that round run inside sprint planning, on work you might build next.

How long should a session take?

About five minutes per contested item. Eight items take about 40 minutes, which leaves 20 minutes of a one-hour meeting for the goal, capacity, and the commitment. The rest of the backlog can wait.

Can we use hours instead of story points?

Yes, if you accept the usual error. Just don't mix hours and points in one session. Hours invite false precision (6.5 versus 8) and anchor on one person's speed, while points only compare work to your references.

When should a team stop?

Stop when the votes no longer change scope: everything comes out a 5, people re-vote to fit the calendar, or they copy a senior card. Switch to fits, too big, or unclear, keep the references for new work, and use completion history when you need a date.