Planning Poker Split Votes: How to Hear the Outliers Without Derailing Refinement

You flip the cards. One engineer played a 3. Another played a 13. The room goes quiet, and then everyone talks at once.

Many facilitators treat planning poker split votes as a problem to fix fast. They want one number so they can move on. That urge is natural, but it wastes the best signal in the session. Below is a short routine for the next five minutes, a clear job for each role, and a firm rule for when to stop voting.

Why planning poker split votes are useful information

A split vote does not mean the round failed. It means the round worked as designed. Secret votes followed by a shared reveal exist to surface disagreement. As Matt Lewandowski of Kollabe puts it, if your team agreed on every estimate at once, one person could just assign the numbers.

What a wide spread usually means

According to the same Kollabe guide, estimates that diverge usually point to one of three things:

• Hidden complexity. One person sees a simple task. Another sees an edge case or a fragile dependency.
• Different scope assumptions. "Build the search feature" can mean full-text search with filters to one person. It can mean a simple dropdown to another.
• Missing requirements. Someone estimates high because they count unknowns that others have not named.

Each cause is useful to find before the sprint starts, and each one costs far more to find in the middle of the sprint.

An exercise for your next split

Take a story that gets a 3 and a 13. Before anyone speaks, write down two stories that each voter could have in mind. For example, the 3 may assume a small change to one screen. The 13 may assume a change to the screen, the data and the tests. You now have a first guess at the hidden assumption, and the discussion will confirm it or correct it.

The reverse also matters. Kollabe notes that unanimous votes on every story usually point to anchoring bias or social conformity, not real agreement. If your team never splits, ask whether people watch each other instead of thinking. Secret votes help, but only if people vote before they look around.

Hear the outliers first: a five-step facilitation routine

Use the same routine each time. When nobody has to decide how to handle a split, the split costs less. The routine also keeps refinement on schedule. TeamRetro's guide sets a target of one to four minutes for the reveal and discussion of each story. That is a practitioner target, not a rule, but it gives you a useful pace to aim for.

Step 1: Check the spread

Look at the cards before you talk. If the spread is a single step, such as all 3s and 5s, take the higher number and move on. A one-step gap does not need a debate. Save the discussion for wide spreads.

Step 2: Ask the lowest and highest voters to speak first

Start with the lowest voter, then the highest. Kollabe calls this the most effective facilitation move in planning poker. It works for three reasons:

It gives the outlier the floor. A person who played a 2 when everyone else played an 8 may stay quiet unless you invite them.

It stops the majority from pressuring one person to conform.

It focuses the talk on the two ends of the range, so the rest of the team can listen and adjust.

Use neutral prompts. "Why did you play so high?" sounds like a charge, so avoid it. Try these instead:

• To the lowest voter: "Walk us through your approach. What does this story look like in your head?"
• To the highest voter: "What risk do you see that may not be obvious?"
• To both: "What did you assume about scope?"

These prompts come from the Kollabe guide. They ask people to describe their thinking, not to defend a number.

Step 3: Protect the outlier

Say it out loud: the highest and lowest cards explain themselves, and that is a feature, not a penalty. TeamRetro lists this as a ground rule worth stating at the start of a session. Then enforce it. If a teammate says "Surely it is just an 8," stop the comment and return to the assumption. The outlier may know something nobody else knows, or they may have misread the story. Either way, you need to hear them.

Step 4: Invite changes, then re-vote once

When both outliers have spoken, ask: "Does anyone want to change their vote based on what you just heard?" Then re-vote. Kollabe reports that teams often converge after one round of outlier discussion. The talk usually reveals a scope gap or a technical risk that changes the shared picture.

Step 5: Decide what the result means

If the votes now agree, record the estimate. Do not pick the average just to end the debate. A number that hides a split gives you a false sense of agreement. If the votes still differ, go to the exit paths in the last section of this article.

Where a tool can help

A tool can run the mechanics so you can spend your attention on the talk. TinyTroop is free online planning poker. It keeps votes secret until the reveal. The reveal shows the average, the median, the spread and the consensus. When votes split, it names the outlier votes so your team knows whom to hear first. The facilitator can restart the round or move to the next story. The tool shows the split, but your team still has to do the listening.

What each role does when planning poker votes split

A split vote can feel tense when nobody knows their part. Give each role one clear job, and share this role card with your team before the next refinement session.

Facilitator. Your job is to keep order, keep time and guard the outlier. In the first minute, say who speaks first. Do not give your own view on the number, and do not let one voice fill the space. Facilitation skill matters in every team meeting, not only in estimation. The daily standup is another meeting where good facilitation keeps the focus on the team.

Product owner. Your job is to clarify scope. When the split comes from a scope gap, answer on the spot if you can. Kollabe gives the same advice: ask the product owner to clarify scope in the room. If you cannot answer, take the story back to refinement instead of guessing to save time. A guess from you can become a hidden assumption for the whole team.

Engineers. Your job is to explain your assumptions and to estimate for the team, not for one person. For experience gaps, Kollabe suggests this question: "If a typical team member picked this up, how much effort is it?" A senior engineer may see a 3 where a newer colleague sees an 8. Both views are honest. If only one person can do the work, flag that as a separate risk. It should not change the estimate.

Design and test voices. Your job is to say what the ticket does not show. TeamRetro advises you to bring the whole delivery team, not only engineers. Its example is simple: a story that reads as a 2 to the developer can be an 8 once someone asks who writes the test plan. If you work in design or QA, speak up when you see work that the ticket leaves out.

Some habits work against all of this. Product owners should not argue the number down. Engineers should not vote to please one person. Facilitators should not treat the quiet voter as a problem. TeamRetro also warns that when a vote feels graded, people give safe estimates instead of honest ones. Judge the team's estimation at the team level, never person by person.

When the split will not close: re-vote limits and exit paths

Some splits do not close after one conversation. That also tells you something: the story is not ready.

Cap re-votes at two

TeamRetro advises that you cap re-votes at two. The first reveal shows the spread. After the high and low voters explain, the second vote should bring the team together. If it does not, TeamRetro says the story is not estimable yet. Split it or send it back for refinement. Do not vote a third time and hope.

This cap is practitioner advice, not a formal standard, but it protects your session. Without a limit, a refinement meeting can turn into a long debate about one story while the rest of the backlog waits.

Pick one exit and name an owner

If the spread is still wide after round two, choose one exit. Say the owner and the next step out loud. Kollabe links each cause to a clear exit:

• Unclear scope: the product owner clarifies it now, or the story goes back to the next refinement session.
• A design debate: this is not an estimation problem. Discuss the trade-offs briefly and pick an approach. If it needs more study, create a spike and estimate the story in a later session.
• Vague acceptance criteria: send the story back. A story that cannot be estimated is not ready, and a vote on it is only a guess.

Splitting can change the numbers

A common exit is to split the story. Teams sometimes worry that the parts must add up to the original estimate. Mike Cohn of Mountain Goat Software says they do not. Part of the reason to split a story is to understand it better. As the team talks with the product owner, it learns more about the work. The new estimates should reflect that knowledge, even when they do not sum to the old number.

So do not defend the first number. A split story with a new total is not a failure. It shows that the team knows more than it did before.

Try it in one meeting

Run an experiment in your next refinement session. Use the five-step routine on every split, and cap the re-votes at two. At the end, ask your team one question: which assumptions came up that nobody had written down? Collect those answers. They show where your stories are weak, which is useful input for the next refinement.

When votes split, ask what each person assumed. Hear the lowest and highest voters first, re-vote once, and send the story back if it still does not settle. If you want a free tool to run the round, Start a free room and share one link with your team.