Scrum planning poker: estimate your backlog without adding ceremony overhead

Who does what in Scrum planning poker?

Scrum Master

Facilitates the session without voting. On pokrr, the SM takes the admin role: presents stories and reveals cards. The role can be transferred to another team member as needed.

Development team

Votes on the complexity of each story. Every developer, QA, and designer involved in the story votes simultaneously, without seeing anyone else's choice before the reveal.

Product Owner

Presents stories and answers clarifying questions. The common practice is not to vote to avoid influencing the team. If the PO votes, they reveal their card at the same moment as everyone else.

What pokrr adds to a Scrum team

• Simultaneous vote, anchoring-free

  No one sees anyone else's vote before the reveal. The senior doesn't set the tone before the team has voted. That's the core rule of planning poker: it applies in person and remotely.

• Fibonacci and T-Shirt in the same tool

  Fibonacci for sprint stories (story points). T-shirt sizing for epics and the roadmap. Powers of 2 and custom decks available to match the team's practice.

• Admin role = Scrum Master role

  The SM creates the room, controls the reveal, and moves to the next story. Multiple admins can be active simultaneously for co-facilitated sessions.

• Per-story timer

  Each story can have its own countdown. Useful for keeping pace on a backlog of 15 to 20 stories without the session running over.

• Join without an account

  The team changes with every hire, every new stakeholder, every discovery session. No team member creates an account. A link is enough.

• Results exportable as Markdown

  After the reveal, the median, distribution, and individual votes can be copied as Markdown and pasted into Notion, Confluence, or a Slack channel.

Common planning poker mistakes in Scrum

1. 1

   The SM gives their estimate before the vote

   Even unintentionally, a verbal estimate before the reveal pulls the team's votes toward that first number. The rule: vote first, then talk.

2. 2

   Treating estimates as commitments

   Story points measure the relative complexity of a story, not a contractual duration. An 8-point story doesn't mean 8 hours or 8 days. The team's velocity across multiple sprints is what gives estimates predictive value.

3. 3

   Estimating during sprint planning

   Sprint planning is for selecting stories and building the plan. Estimation should happen earlier, during backlog refinement. A sprint planning that starts with unestimated stories turns into an unplanned estimation session.

4. 4

   Moving on without discussing large divergence

   If someone votes 2 and someone votes 13, skipping the discussion defeats the purpose of the session. The gap signals a disagreement about the story definition, an unidentified dependency, or an undisclosed technical risk.

Frequently asked questions

When in the sprint should planning poker happen?

Most commonly during backlog refinement, mid-sprint, to prepare stories for the next sprint. Sprint planning can include quick estimation, but complex stories should be estimated beforehand.

How many stories should be estimated per session?

Between 8 and 15 stories for a 60-to-90-minute session with a team of 5 to 7 people. Beyond that, concentration drops and estimate quality degrades.

Should the Scrum Master vote?

Not in common practice. The SM facilitates the session. If they vote, they influence the team, even unintentionally. They can note their own estimate separately for comparison, without revealing it before the collective vote.

Can pokrr track velocity?

No. pokrr is a session tool. Rooms expire after 4 hours of inactivity and no data is retained. Sprint-by-sprint velocity tracking belongs in your project management tool (Jira, Linear, Notion).

Does pokrr integrate with Jira?

No native integration. Copy the session results as Markdown from the interface and paste them directly into your Jira backlog.