Scrum Poker: Estimation Inside the Scrum Framework

“Scrum poker” is simply planning poker as practiced by Scrum teams. The mechanics are identical — vote privately, reveal together, discuss the outliers — but the value comes from how estimation plugs into the Scrum events, roles, and artifacts. This guide focuses on that fit rather than repeating the card-by-card rules.

Where estimation happens in Scrum

Scrum does not prescribe an estimation technique, but two events are where scrum poker earns its keep:

Most of the estimating should happen in refinement, not sprint planning. A team that arrives at planning with a refined, pre-estimated backlog can spend the meeting deciding what to commit to instead of arguing about sizes. If you find sprint planning dominated by estimation, that is a signal to refine earlier and more often.

Who does what

• Product Owner: presents each backlog item, clarifies intent and acceptance criteria, and answers scope questions. The PO does not vote — they own the why, not the how big.
• Developers (the whole delivery team): vote. Anyone who contributes to getting a story to done — backend, frontend, QA, design — casts an estimate.
• Scrum Master / facilitator: runs the round, timeboxes discussion, and protects the process from anchoring and dominance. They do not impose numbers.

A refined story is a prerequisite

Scrum poker only works when the item is understood. Many teams adopt a lightweight Definition of Ready before an item can be estimated:

• The story has a clear user-facing outcome.
• Acceptance criteria exist and are testable.
• Dependencies and obvious unknowns are noted.
• It is small enough to plausibly finish in one sprint.

How points connect to velocity

Story points only become useful once they accumulate into velocity — the number of points a team completes per sprint. After a few sprints, a team that consistently finishes about 24 points can forecast roughly how much of the backlog fits in the next sprint.

Consider a team's recent history:

A rolling average of ~24 points is a reasonable planning baseline. It is a forecast, not a target to maximize — and it is specific to this team. Comparing one team's velocity to another's is one of the fastest ways to break the technique, because points are calibrated locally.

Scrum poker anti-patterns

• Estimating in hours dressed up as points. If your “points” map one-to-one to a day of work, you are doing time estimation with extra steps.
• Management using velocity as a productivity score. The instant points become a target, teams inflate them and the forecast stops working (Goodhart's law in action).
• Re-estimating completed work. Points size future effort; do not adjust them after the fact to make a sprint look better.
• Skipping refinement. This pushes all estimation into sprint planning and blows the timebox.

A sample refinement agenda

1. PO presents the next 5–8 candidate stories (2 min each).
2. Team asks clarifying questions and notes acceptance criteria.
3. Scrum poker vote and discussion per story.
4. Split anything that lands at 13 or higher.
5. Flag items that are still unclear for follow-up.

Frequently asked questions

Is scrum poker different from planning poker?

No — they are the same technique. “Scrum poker” just emphasizes its use within Scrum. You will also see it called pointing poker or agile poker.

Should the Scrum Master vote?

Only if they also do delivery work on the story. Their primary job during the round is to facilitate, not to estimate.

What deck should a Scrum team use?

A modified Fibonacci deck (1, 2, 3, 5, 8, 13, 21) is the default for sprint-level work. T-shirt sizes suit coarser roadmap estimation.

Run scrum poker with your team

PlanITPoker gives Scrum teams a free real-time room with Fibonacci and T-shirt decks and instant vote distributions — no signup required. Pair it with solid facilitation practices to keep sessions fast and fair.