Scrum poker online, free for your whole team

If you came here wondering whether your team has been using the wrong name: it has not. Planning poker is the original term, described by James Grenning in 2002 and popularised by Mike Cohn a few years later. Scrum poker is what most teams say out loud, because the ceremony lives inside a scrum team’s refinement. Sprint poker and estimation poker are two more names for the identical technique.

Nothing about the method changes with the label. Everyone votes privately, all cards reveal at once, and the disagreement is the part worth talking about. If a colleague uses one name and you use another, you are describing the same fifteen minutes of the same meeting.

Scrum defines four events, and estimation is not one of them. That surprises teams who assume there must be an official ceremony for it. There is not — sizing happens inside backlog refinement, which the Scrum Guide treats as an ongoing activity rather than a fixed meeting.

In practice most teams book it once a sprint, an hour or less, somewhere around the middle. That timing matters: refine too early and the items are not understood yet, too late and sprint planning turns into a refinement session with a deadline attached.

Keep estimation out of sprint planning if you can. Planning has to answer what the team commits to and how it will be built, and a room that is still arguing about whether something is a 5 or an 8 has not got to either question. A refined backlog with numbers already on it turns a two-hour planning meeting into a forty-minute one.

The daily scrum and the retrospective are the wrong places entirely, though the retro is the right place to notice that your estimates have been consistently low for three sprints and decide what to do about it.

The developers vote. Everyone who might pick the item up, which in a cross-functional scrum team includes testers, designers and anyone else whose work is part of “done”. A single number covering the whole item is the point; splitting an estimate by discipline rebuilds the handoffs scrum exists to remove.

The product owner presents and answers. They explain the item, take the questions and clarify scope, but they do not vote. Estimating work you will not do adds noise, and a product owner’s number carries more social weight than they usually intend.

The scrum master facilitates. Keeps the round moving, asks the outliers to explain, and calls it when an item needs splitting rather than a third vote.

Stakeholders watch. Join them as spectators. They hear the reasoning, which is usually what they wanted, and they are excluded from the vote count and the agreement score so their presence cannot move the number.