Use Point Poker as a scrum poker app for sprint planning and backlog refinement, with fast, unbiased story-point discussions across a distributed team.
Scrum poker and planning poker are the same ceremony under two names: the team sizes work relatively, votes simultaneously, and talks only about the gaps.
Rooms hold up to 20 people including facilitators, which covers a full scrum team plus product, design, and QA in one session.
The ceremony earns its time in the two places where the team has to agree on size before it commits to anything.
Most of the value is in the reveal. Everything else is logistics.
Estimation meetings sprawl when the discussion has no stopping rule. These are the ones that hold.
Scrum poker is a consensus estimation technique where each member of a scrum team privately picks a card representing the relative size of a backlog item, everyone reveals at once, and the team discusses the disagreements before agreeing a number. It is the same practice as planning poker — scrum teams simply tend to call it scrum poker.
No. The Scrum Guide does not mention planning poker, story points, or any specific estimation technique — it only says the Developers size the work. Scrum poker is a widely used convention that fits Scrum well, not a rule you are failing to follow if you estimate some other way.
Everyone who will do the work votes — developers, QA, and anyone else delivering the item. The Product Owner answers questions about intent but does not usually vote, since they are not estimating their own effort. The Scrum Master facilitates and stays out of the voting entirely.
Ask the highest and lowest voters to explain what they are seeing — they are usually looking at different work. Then re-vote. If a second round still splits the table, the story is generally too vague or too large, and splitting it is a better outcome than settling on a middle number nobody believes.
Around a minute or two per item once the team has a baseline, so a refinement session of ten to fifteen items fits comfortably in half an hour. Sessions that run long are usually a symptom of items arriving without acceptance criteria, not of the estimation itself being slow.