Scrum Poker Online

What is scrum poker?

Scrum poker is a lightweight estimation method used during backlog refinement and sprint planning. Each team member picks a card privately, everyone reveals at the same time, and the team discusses large differences before voting again.

The goal is not perfect precision. The goal is a shared understanding of scope, complexity, and uncertainty. That makes scrum poker especially useful for cross-functional teams working on product development.

Why use scrum poker online?

• Remote-friendly: share one link with the whole team.
• Less bias: reveal all votes together instead of discussing estimates one by one.
• Faster meetings: keep sprint planning focused and timeboxed.
• Clearer decisions: discuss outliers and hidden assumptions before committing.

If you want a browser-based tool with no signup, you can create a free scrum poker session and invite your team in seconds.

Scrum poker vs planning poker

In practice, the two phrases usually mean the same thing. Some teams prefer "scrum poker" because they use it inside Scrum ceremonies. Others search for "planning poker" when looking for an online estimation tool.

On ScrumVote, both workflows are the same: create a room, share the link, vote simultaneously, reveal the cards, and align on story points.

How to run a scrum poker session step by step

Running a scrum poker session follows a consistent pattern regardless of whether the team is co-located or remote. Each voting round has three phases: setup, voting, and discussion. Keeping these phases distinct prevents the most common failure mode — premature anchoring through discussion before votes are cast.

Before voting: present the story clearly

• Read the story aloud: do not assume everyone has read it. The shared reading creates a common starting point and surfaces immediate clarifying questions.
• Answer clarifying questions: allow the Product Owner or a team member with context to answer factual questions — but do not allow discussion of approach or complexity before voting. Approach discussions anchor votes.
• Confirm the story's acceptance criteria: if the acceptance criteria are missing or ambiguous, defer the story for refinement rather than estimating through uncertainty.

During voting: independent estimates only

• Everyone votes simultaneously: in a physical setting, hold cards face-down; in an online tool, vote without revealing until the facilitator triggers the reveal. Simultaneous reveal is not a formality — it is the mechanism that prevents anchoring.
• Include everyone: every team member who will work on the story should vote. Observers (stakeholders, PO in some team setups) can watch but should not vote in the initial round.
• Do not reveal your vote early: saying "I'm probably thinking a 5" before the reveal defeats the purpose. Silence the chat during the voting phase.

After revealing: structured discussion

• Ask the extremes to speak first: the highest and lowest voters explain their reasoning. This surfaces assumptions on both ends of the spectrum before the middle converges.
• Re-vote after discussion: a second round with the same story usually converges significantly. If not, note the blocker and move on with a provisional estimate.

Where scrum poker fits in Scrum ceremonies

Scrum poker is not confined to a single ceremony. While it is most commonly associated with sprint planning, agile teams use it throughout the sprint cycle wherever shared estimation adds value.

Scrum poker in backlog refinement

Backlog refinement is the best home for scrum poker. Stories estimated during refinement arrive at sprint planning already sized, which makes planning sessions dramatically faster. Teams that estimate during refinement typically spend 30–45 minutes on sprint planning; teams that skip refinement often spend 2–3 hours.

During refinement, the team has more tolerance for deep discussion. If a story triggers a long debate, there is no sprint commitment at risk — the facilitator can simply defer the story and add clarification tasks.

Scrum poker during sprint planning

Sprint planning poker is appropriate for stories that arrived unestimated, stories whose scope changed significantly since refinement, and new high-priority items inserted by the Product Owner. Keep it brief — sprint planning has a hard timebox and every minute spent estimating is a minute not spent on commitment.

A useful rule: if more than 30% of sprint planning stories require estimation, refinement quality has fallen below acceptable. Use that threshold as a feedback mechanism.

Scrum poker for distributed and remote teams

Distributed teams gain disproportionately from online scrum poker tools. The physical distance that fragments other meetings actually helps scrum poker: everyone is already staring at the same screen, no one can whisper their vote to a colleague, and the facilitator has equal visual access to all participants.

Synchronous remote scrum poker

Run synchronous remote scrum poker sessions exactly like in-person sessions, with one addition: keep a video channel open during discussion. Facial expressions and hesitation are important signals. A participant who looks uncertain before voting low is not the same as one who looks confident.

Use screen-sharing to keep the current story, its acceptance criteria, and the revealed votes all visible simultaneously. Context-switching between tabs during discussion breaks flow.

Asynchronous estimation for teams across time zones

For teams spanning more than 4–5 time zones, synchronous sessions may be impractical. Async scrum poker works by opening a voting window (typically 24 hours), then reviewing results in a brief follow-up meeting or async thread.

The limitation of async estimation is the loss of live discussion. Compensate by requiring voters to leave a brief note explaining any vote above 8 or any "?" vote. This creates a partial discussion record that the facilitator can use to prepare targeted follow-up questions.

Regardless of sync or async, use the same online tool consistently. Teams that mix physical card decks for in-office participants with phone screenshots for remote participants inevitably create first-class and second-class estimation experiences.

Choosing the right story point scale for scrum poker

The scale you choose shapes how your team thinks about effort. It is worth spending one retrospective deliberately discussing which scale fits your work patterns before defaulting to whatever the tool offers.

The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is the default for most teams and the most widely documented. It has a well-understood theoretical basis and the most peer-reviewed research on its effectiveness. Unless your team has a specific reason to deviate, start here.

• Modified Fibonacci (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100): adds fractional and very large values. Useful for teams that frequently estimate very small tasks and genuinely large epics in the same session.
• Powers of 2 (1, 2, 4, 8, 16, 32): mathematically clean, intuitive for engineering teams, and naturally drives story splitting at higher values. Less psychological research behind it but works well in practice.
• T-shirt sizes (XS, S, M, L, XL, XXL): ideal for early discovery or roadmap planning where exact point values are premature. Convert to points during refinement once stories are better understood.