How to run planning poker without losing the afternoon

Forty minutes into sprint planning, on story nine of twenty-three, somebody re-explains the same card for the third time and two people quietly open Slack in another tab. Everyone in the room can feel that the meeting stopped being useful about twenty minutes ago, and nobody wants to be the one to say so.

That is not planning poker failing. That is a room using planning poker on work that never needed it.

Done properly the whole thing takes about fifteen minutes and produces something you cannot get any other way: a clear view of where your team disagrees about the work, found before you commit a sprint to it. Here is how to get that in fifteen minutes instead of forty.

Do the setup before anyone joins the call

Most of what makes a session drag has already happened by the time the first card is played.

You need a reference story. Pick one your team finished in the last month or two, that everybody actually touched or reviewed, and agree it is a 3. Not a hypothetical, not something from the archive that only one person remembers. Every estimate in the session is then answering one question, is this bigger or smaller than that, and comparison is a thing humans are good at. Estimating in the abstract is a thing we are terrible at, which is why story points exist at all.

A second anchor helps more than most teams expect. Keep the 3, and add something at the top end you agree is an 8. With one reference everything drifts toward the middle of the scale; with two, a story has to justify landing between them.

Then, and this is the part that saves the afternoon, sort the backlog before the meeting. Whoever refines the backlog can usually mark two thirds of the items as obvious. Those do not need cards. What goes into the session is the pile nobody was confident about.

Bring six stories, not twenty-three

If you have twenty-three items to size, planning poker is the wrong instrument. Sizing forty stories by dragging them into rough piles takes ten minutes and gets you numbers within a point of what the cards would have produced. We wrote about that and three other ways to size a backlog, including the case for simply asking the two people who will do the work.

Cards are for the stories where you expect the room to disagree. Unfamiliar territory, a new integration, anything with real money or a real external date on it, anything two people have already talked past each other about once. If you can confidently predict everybody will show the same number, you already have your estimate.

Six to eight of those is a session. Twenty-three is an endurance event.

The round itself

Read the story out loud, or have the person who wrote it summarise it in two sentences. Take questions, briefly. Then everybody picks a card privately and the cards turn over together.

The simultaneous part is not theatre. The first number said out loud in a meeting stops being an opinion and becomes a suggestion, and every later estimate bends toward it. That is anchoring, it is well documented, and hiding the cards until they all turn over is a genuinely effective defence against it. It is the only reason the ritual exists.

Two details that matter more than they look. Whoever is facilitating should sit the round out rather than voting, because a facilitator with a card in play stops facilitating. And let people take a card back before the reveal without any comment, because a room where changing your mind is awkward is a room that stops thinking.

The spread is the output, not the number

Here is where most sessions throw away the thing they came for.

Three people show a 3 and one shows a 13. The instinct is to average it to 5 and move on, and that is precisely the wrong move, because nobody in that room voted 5. Four people just looked at the same sentence and pictured four different pieces of work, and you have found that out for the price of one round, before the sprint started. That is the entire value of the exercise.

So ask the 13 what they were sizing, and then ask the 3. Almost always one of them knows something. There is a migration in there. There is a service that has to be touched, and only one person has touched it. Or the story is genuinely two stories wearing one title, which is the most common answer of all.

Give it two minutes on a timer, then vote again. A third round almost never changes the number, it just costs the room its attention. If the second vote still splits, that is your answer: the story is not understood well enough to commit to, and it goes back to refinement rather than into the sprint.

And split anything that lands above a 13. A card that big is the team saying it cannot see the bottom of the work yet. Estimating it harder does not make it smaller.

We argued against building this, and then built it

A few weeks ago we published a post explaining why Scrumpy did not have a planning poker feature. The argument was that card voting is a meeting format, that a board is a poor place to hold a meeting, and that building it into the sprint workflow would amount to endorsing a calendar invite most four-person teams should not be sending.

We still believe the second half of that. We were wrong about the first half.

The mistake was treating "should this be a feature inside the board" and "should this exist at all" as the same question. Teams kept asking us for planning poker, and the honest thing to notice was that they were not asking for a fortnightly ceremony, they were asking for a room they could open on the two Tuesdays a quarter when a story genuinely splits the team. That is a good reason to want the cards. It is just not a good reason to bolt them onto a sprint.

We are not the only ones giving this away, and it is worth knowing where each of the free tools stops being free before you settle on one. We built our room and put it outside the product, free, at scrumpy.it/tools/planning-poker. No account, no email address, no participant limit, nothing to install. Type a name, share the link, everybody plays a card, and the cards turn over on their own the moment the last person has played. The room deletes itself about twelve hours after the last person leaves, and we keep no copy of what you were estimating.

We will be straightforward about why it is free: it is how people who have never heard of Scrumpy will meet us. That is the whole arrangement, and it seemed better to say so than to pretend otherwise.

If you already use Scrumpy, the same room is in your sidebar, dealing your team's own configured point scale rather than a generic Fibonacci deck, with your backlog on the table. When the round ends, one click writes the agreed number onto the story, which removes the most annoying part of the whole exercise: the bit where somebody transcribes fifteen estimates into a tracker afterwards and gets two of them wrong. If your team would rather not have it there at all, there is a switch for that in team settings.

Nothing in the product will ever suggest you hold a session. It is a room you open, not a mode you are put in.

What to try next sprint

Take your next planning meeting and cut the estimation part down to the six stories you are least sure about. Anchor them against one finished story everybody remembers, run the cards, and spend the time you save talking about what you are actually trying to finish.

If it turns out all six were obvious, that is a useful result too. It means your backlog is in better shape than you thought, and you can get sprint planning back to the conversation it was supposed to be.