Scrum Poker Online: Estimation in Sprint Planning

Scrum poker is what many Scrum teams call planning poker: everyone picks a card in secret, the cards are revealed together, and the team talks about the spread. You’ll also hear it called pointing poker, because the cards usually carry story points. Whatever the name, the mechanics are identical, and they’re laid out with a worked example in our planning poker guide. The Scrum-specific questions are different ones: when in the sprint to estimate, who runs the session, and what the team does with the numbers once it has them.

What the Scrum Guide actually says about estimation

The Scrum Guide has little to say on the subject. It asks for Product Backlog items to be refined until they’re small enough to be done within a sprint, and it says the Developers who will do the work are responsible for sizing it. It doesn’t mention story points, planning poker, velocity or Fibonacci numbers anywhere.

Those practices grew up around Scrum rather than inside it. Story points and velocity came largely from Extreme Programming, and agile coaches spread them through Scrum teams during the 2000s. So a team can estimate in points, in ideal days or in T-shirt sizes, or skip estimation entirely, and still be doing Scrum by the book.

Knowing this helps when a team starts to resent its estimation sessions. Nothing in the framework obliges you to keep them. They should stay only if they help the team understand upcoming work and plan sprints it can finish, and if they don’t, it’s legitimate to change them or drop them.

Teams run scrum poker in two places, and where you put most of it changes how the sprint feels.

Refinement, still called grooming in some teams, is the ongoing work of making backlog items clear and small enough to pull into a sprint. Many teams hold a session once or twice per sprint, an hour at most. This is the natural home for scrum poker. The stories are a sprint or two away, so there’s time to chase the product owner for answers, and a story that turns out enormous can be split long before anyone commits to it.

Estimating during sprint planning

Sprint Planning is for deciding what goes into the next sprint and how the team will deliver it. When most stories arrive already estimated, planning goes quickly: the team compares the total with its recent velocity and adjusts the selection. A story or two might get re-estimated if something new came up since refinement.

Teams that leave all their estimation for sprint planning tend to have long and draining planning meetings. By the fifth unclear story, people vote for whatever gets them out of the room fastest. If that sounds familiar, try moving estimation into refinement.

The Scrum Master as facilitator

A Scrum Master who isn’t also a developer on the team doesn’t vote. Their job during scrum poker is to keep the process honest and moving.

Before the vote, they check that the story has been understood. A quiet “does anyone have a question they haven’t asked?” often surfaces the one thing a developer was unsure about but didn’t want to raise.

During the vote, they protect the silence. If someone says “easy, that’s a 2” before the reveal, the Scrum Master can ask the team to re-vote, or simply remind everyone to keep numbers to themselves. It only needs to happen a couple of times before the team does it on its own.

After the reveal, they ask the highest and lowest voters to explain, by name, the same way every time. Once this is routine, being the outlier stops feeling like being singled out.

They also watch the clock. A soft limit of five minutes per story keeps a session from stalling, and after two or three rounds without agreement, the Scrum Master parks the story and makes sure someone owns the open question.

Good facilitators talk less than you might expect. Most of the value comes from the developers explaining their numbers to each other, and the Scrum Master’s main contribution is making room for that to happen.

When someone plays “?” or ☕

Both cards deserve a proper response rather than a shrug. “?” says the story is missing information, which is a signal for the Scrum Master to find out what’s missing, and ☕ says the team needs a pause, which it should get. The Fibonacci page explains both cards and how to handle them.

Bugs, spikes and technical debt

Scrum teams argue about whether to estimate work that isn’t a user story. There’s no single right answer, but it helps to be consistent.

Bugs. Some teams estimate bugs like any other backlog item, so they count toward velocity. Others leave them unestimated and accept that velocity reflects only new features. The second approach makes velocity look lower in bug-heavy sprints, which some teams find useful as a warning sign.

Spikes. A spike is a time-boxed investigation, often created after someone plays “?” on a story. Because it’s time-boxed, many teams don’t point it at all; they agree on a limit, say two days, and treat it as capacity taken off the sprint.

Technical debt. Refactoring and upgrades compete with feature work for the same sprint, so estimating them in points makes the trade-off visible to the product owner. A database driver upgrade that the team plays at 8 is harder to postpone forever than one hidden inside other stories.

Scrum poker and velocity

The reason most teams estimate in points is velocity: the number of points completed per sprint, used to decide how much to pull into the next one. Scrum poker helps keep that number meaningful, because the whole team agrees on each estimate and the scale doesn’t drift the way it does when one person estimates alone. How velocity works, and the myths around it, are covered on the story points page.

When you don’t need scrum poker

Plenty of good teams skip it.

If your stories are all roughly the same size, you can split everything down to a day or two of work and count stories instead of summing points, which is a perfectly valid way to plan.

A team of two or three people may get by with a quick conversation, although a silent vote still helps against anchoring, even in a small group.

Kanban teams and others working in continuous flow often track cycle time instead of velocity and never estimate individual items.

And if the estimates never influence planning or forecasting, producing them is waste. Either start using the numbers or stop generating them.

On the other hand, if your team regularly commits to more than it finishes, or sprint planning feels like guesswork, a few sprints of consistent scrum poker usually make the problem visible. You can run your next refinement session in a free online room, with no sign-up for anyone on the team.

Scrum poker for Scrum teams