After the Planning Poker Reveal: When to Re-Vote, Split or Park a User Story

The cards flip, and you see 3, 3, 5, 13 and a question mark. For a second, nobody talks. Then the most confident person in the room speaks, and the discussion drifts. Ten minutes later, your team has voted three more times. The final number is the one people accepted because they were tired.

This guide is for teams that already run planning poker. It covers the few minutes after the reveal: how to read the result, which questions to ask before you split or park a user story, how long to talk, and when to stop voting. The rule is short. Talk briefly, re-vote once, and then choose one clear outcome: accept, split, park, or send back to refinement.

Every role has a job in those minutes. The facilitator reads the round and keeps the clock. The product owner answers scope questions. The engineers name risks and unknowns. Together, you decide when to split or park a user story instead of forcing a number onto it.

What the reveal tells you before anyone speaks

Read the reveal before you open the discussion. In about ten seconds, the cards tell you whether your team needs to talk at all, and what kind of talk it needs.

A close spread: confirm and move on

When the votes sit close together, your team already shares an understanding of the work. Say the number out loud, ask if anyone objects, and move on. Do not start a discussion only because the meeting has time for one.

Some teams agree in advance what to do when votes land on two neighbouring cards, such as 3 and 5. A common choice is to take the higher card. Whatever rule you pick, agree on it once and write it down. Then use it every time, so nobody has to argue about it in the middle of a round.

A wide spread: a conversation, not arithmetic

When votes cover several cards on the deck, people are not looking at the same work. One person may know about a dependency. Another may assume a smaller scope. A third may see test effort that nobody mentioned.

You use secret votes and one shared reveal because of this difference. The goal is to make disagreement visible early. So a wide spread does not mean the technique failed. It means the technique did its job.

The average can hide the signal

Many facilitators and many tools calculate an average. The average is a useful summary when the spread is close. When the spread is wide, it hides the disagreement that the reveal was meant to show.

Suppose your team plays a 3 and a 13 and settles on 8. Nobody learns why one person saw a small task and another saw a large one. The 8 looks like agreement, but it is only a midpoint. Look at the spread first. Use the average as a summary, and do not use it as the decision.

A ? is a stop sign

A question mark is not a missing vote. It means that someone cannot size the story with confidence. Often the story lacks context, acceptance criteria, or a clear edge.

Do not ask, "Does anyone have a real number?" Ask the person who played the ? what they need to know. Their answer often decides the outcome before anyone re-votes.

Reading the example round

Go back to the round: 3, 3, 5, 13 and one ?. Here is how the facilitator reads it in ten seconds:

• The spread runs from 3 to 13. That is wide, so the team must talk.
• The two 3s and the 5 are close, so most of the team shares one view.
• One person sees much more work than the others. The team needs to hear that view.
• The ? means one person is missing information. That gap may be the real issue.

The facilitator does not average this round. Instead, the facilitator opens a short, timed discussion.

Five questions and a fixed timebox for the talk

A good talk after the reveal is short and structured. Use the same questions every time, give every story the same timebox, and let each role do its job.

Who speaks first

Ask the lowest voter to explain first, then the highest voter, then everyone else. Hidden votes stop one person from anchoring the number. But they do not stop the most senior or most confident person from ending the discussion. When the lowest voter speaks first, quieter team members can share their context instead of agreeing with the loudest view.

The SprintBee backlog refinement guide makes two related points. When the spread is wide, focus on the highest and lowest votes and "ask what those people saw that others didn't". Also, park open questions that need research instead of solving them on the spot. For more on the first step, read our guide to hearing the outliers when planning poker votes split. This article picks up where that one ends: the decision that comes next.

The five-question card

Put these five questions where the facilitator can read them aloud:

1. Find the gap. What did you see that others missed? Ask the lowest and highest voters.
2. Clarify scope. What is unclear in scope? The product owner answers.
3. Name unknowns. What is the biggest unknown? Engineers name the risk, the dependency, or the gap in knowledge.
4. Shrink it. What would make this smaller? Look for a slice of value the team could deliver first.
5. Find an owner. Who can answer it? If nobody in the room can answer the open question, name the person who can.

The questions move from understanding to action. The first three find the cause of the spread. The last two point to an outcome: a smaller story, or a question with an owner.

Roles in the talk

The product owner answers scope questions: what is in, what is out, and what "done" means for this story. The product owner does not argue about the size. The size comes from the people who will do the work.

Engineers name risks and unknowns in plain words. "I am not sure the old API supports this" is more useful than "It feels like a 13." When an engineer can name the unknown, the team can decide what to do with it.

The facilitator keeps the talk on the five questions. When the discussion moves into detailed design, the facilitator brings it back. Design work belongs after the estimate, not inside it.

Park research questions; do not solve them

Some questions need research: a spike, a call with another team, or a look at old code. Do not try to answer them in the room. Write the question down and carry it into the outcome step. If the room cannot answer a question within the timebox, that is a strong signal for the park outcome.

Keep the timebox

Before the session starts, agree on a fixed number of minutes for each story's discussion. Use the same limit for every story, so it feels fair and nobody takes it personally. When time runs out, the facilitator stops the talk and calls the re-vote.

Timebox the whole session as well, not only each story. Long estimation sessions tire people, and tired people agree to numbers they do not believe. If stories remain when the session ends, schedule another session instead of rushing the last ones.

The timebox is a facilitator habit. Use a phone, a kitchen timer, or a clock on the wall. Say out loud when one minute remains.

One re-vote, then choose an outcome

After the talk, re-vote once. If the votes still do not converge, stop voting and choose an outcome. Do not start a third round.

Why one re-vote

One re-vote is worth the time. Your team has heard new information, and the new votes show whether that information changed people's view. Further rounds rarely add information. The spread may get smaller after that, but often because people want the meeting to end, not because they agree.

TeamRetro's list of planning poker mistakes puts the limit this way: "Two votes per story is the right ceiling. Heading for a third? The story isn’t ready, so split it, send it back to refinement, or punt." Two votes means the first vote plus one re-vote. In this guide, "punt" becomes "park", with an owner and a question so the story does not disappear.

The four outcomes

When the re-vote ends, pick one of four outcomes. Each outcome has a clear next step.

Accept. The spread is close, and the story fits comfortably in one sprint. Record the estimate and move to the next story.

Split. The story hides several pieces of value. The talk showed separate parts, such as a simple main path and a complex edge case. Split the story into smaller stories that each deliver value, and estimate each one.

Park. One open question stops the team from sizing the story, and that question needs research. Write down three things: one owner, one question, and a date to revisit. Without an owner and a date, a parked story becomes a forgotten story.

Send back to refinement. The story lacks context or acceptance criteria, and the team cannot agree on what the story is. Return it to the product owner for more work before anyone estimates it again. Our guide on how to run a backlog refinement meeting that ends on time covers the wider meeting agenda where that work happens.

A decision table for the room

Keep this table next to the five-question card. Read the signal on the left, then act on the right.

Choose fast; the outcome is not permanent

If the team cannot agree on an outcome, the facilitator proposes one from the table. The product owner confirms any change to the backlog, such as a split or a return to refinement. Then move on.

No outcome is final. A parked story comes back. A split story can be split again. What matters is that the round ends with a next step instead of a fourth vote.

How to split or park a user story in the room

Decide the outcome, then act on it before the next story starts. A decision that nobody writes down in the room is easy to lose.

Re-estimate split stories without forcing the sum

When you split a story, estimate each new story from the start. Do not divide the old number among the parts. Mike Cohn of Mountain Goat Software puts it plainly: "Part of the reason for splitting the stories is to understand them better." That improved knowledge should show in the new estimates, and in his words, "If those estimates don’t sum to the same value as the original story, so be it."

So if a 13-point story becomes three stories, the new estimates may add up to more or less than 13. That is normal: your team knows more than it did ten minutes ago.

Write the parked story so it comes back

A parked story needs four short lines. Write them while everyone is still in the room:

• Story: the original title.
• Owner: one named person, not a group.
• Question: one question the owner will answer.
• Revisit: the date or the session where the team looks at the story again.

Put the parked story where your team will see it in the next refinement session. Do not leave it at the bottom of a long backlog.

A worked example

Your team discusses a 13-point story, re-votes once, and the votes still spread. The talk shows three separate pieces of value, and the product owner agrees to split the story. The team adds three new stories and runs a round on each, with no more than one re-vote per story.

Two of the new stories converge, and the team accepts them. The third depends on an open question that needs research, so the team parks it with an owner, a question, and a revisit date. The 13-point story is gone. Three smaller stories with clear next steps replace it.

Where your planning poker tool fits

TinyTroop is a free planning poker tool that can run the round. Votes stay secret until the reveal. The reveal shows the average, the median, the spread, and the consensus. When the votes split, it names the outlier votes, so you know whom to hear first.

Restart gives you the one re-vote, and next story moves the room on. The story list lets you add the split stories and reorder parked ones. It has no timer, so the timebox stays your habit: keep a clock next to you.

The takeaway

Take one rule into your next session. Read the reveal, talk for a fixed time with five questions, re-vote once, and then accept, split, park, or send back. Never vote a third time on the same story. Every story leaves the round with an estimate or a named next step.

Try the rule on one story at your next refinement session. Start a free room, share the link with your team, and keep the five-question card next to you when the cards flip.