Ace-The-BacklogPlanning poker for agile teams

Paste your backlog items, set up the voting roles, and share the room link. No account needed.

Do not paste confidential data, customer information, or secrets into ticket fields.

0 / 200
01The process

How planning poker works in this tool

Sprint planning or backlog refinement, remote or in-person — three steps and you're estimating together.

  1. PROJ-123 — Login button
    PROJ-124 — Navbar fix
    PROJ-125 — Email alerts

    01Paste your backlog

    Drop in tickets one per line — JIRA keys, plain text, or short descriptions. Up to 200 items per session.

  2. 5
    8h
    M

    02Set roles and scales

    Pick which roles vote (e.g. Dev, QA, Design) and the estimation scale each one uses. Story points, hours, days, or T-shirt sizes.

  3. /room/8f3a-7c2b
    ABCD

    03Share the room link

    Send the URL to your team. Everyone votes live in their browser — no account needed. Reveal, discuss, lock in the final estimate.

02Use cases

Built for the way agile teams actually work

Sprint planning

Walk through the next sprint's tickets together, get estimates from every role that touches the work, lock them in, ship a confident plan.

Backlog refinement

Refine and size your backlog before sprint planning so the team starts the sprint with clean, agreed-upon estimates rather than rough guesses.

Remote and hybrid teams

Real-time voting in any modern browser. Share the room link in Slack, Teams, Zoom — no installs, no plugins, no logins.

Multi-discipline estimation

Configure separate voting rounds for Dev, QA, Design, Product or Ops on the same ticket. Capture the full effort picture, not just engineering.

DevQADesignProductOps
03FAQ

Frequently asked questions

Planning poker is a consensus-based estimation technique used by agile teams to size backlog items. Each team member picks a card with their estimate; cards are revealed simultaneously so nobody anchors on the loudest voice. Differences trigger a short discussion, then the team re-votes.

Paste your backlog items, configure the voting roles and estimation scale, then share the room link. Everyone joins live in their browser — no account needed. Each role votes in turn per ticket, you reveal the cards, discuss outliers, and lock in a final value.

Yes — completely free, no sign-up, no ads, no upsell. Sessions auto-delete after 24 hours.

No. Pick a name when you join a room and you're in. We store nothing about you on our servers beyond what's needed for the live session, and that data is deleted after 24 hours.

Yes — that's the primary use case. Real-time voting works in any modern browser. Share the room link via Slack, Teams, Zoom chat, or however your team communicates.

Four scales out of the box: Fibonacci story points (1, 2, 3, 5, 8, 13, 21), person hours (1h to 40h), person days (0.5d to 13d), and T-shirt sizes (XS to XXL). You can pick a different scale per voting role.

Yes — configure up to 5 roles per session (e.g. Dev, QA, Design, Product, Ops). Each role votes in its own round, so you can capture estimates from multiple perspectives on the same ticket.

Yes. Anyone can join as a Spectator — they see the room and the results but don't cast votes. Useful for stakeholders, observers, or facilitators.

Session data is automatically deleted 24 hours after the room was created. Your display name and role preference are saved locally in your browser, until you clear browser data.

Yes — at the end of a session there's a one-click CSV export with each ticket and the final estimate per role. Works in any spreadsheet app.

Story points are a relative effort unit that combines complexity, uncertainty, and work volume into a single number — popularised by Mike Cohn in Agile Estimating and Planning (2005). Most teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) because the widening gaps mirror how estimation accuracy drops for larger tasks. A 5-point story isn't five times harder than a 1-point story — it's just clearly bigger.

Functionally none — both terms describe the same consensus-based estimation technique. Planning poker is the original name coined by James Grenning in 2002 and popularised by Mike Cohn; scrum poker is the more recent alias that emphasises its use inside Scrum sprints. Tools and rules are identical.

Pick by what you're estimating: Fibonacci story points for backlog refinement and sprint planning (relative complexity), hours for tasks under 1-2 days where the team has shared standards, days for milestones, T-shirt sizes (XS to XXL) for early-stage rough sizing before stories are broken down. This tool lets each voting role pick its own scale per session, so Dev can vote in Fibonacci while Design votes in T-shirt sizes on the same ticket.

Research on the Wideband Delphi technique (planning poker's parent method, Boehm 1981) found that group estimation cycles converge on values significantly more accurate than any individual expert's first guess. The reveal-simultaneously mechanic is the key: it removes anchoring on the loudest voice and surfaces hidden assumptions, which is the single largest source of estimation error in software projects.

James Grenning invented it in 2002 as a faster alternative to Wideband Delphi. Mike Cohn popularised it through his 2005 book Agile Estimating and Planning. It has since become the most widely used estimation technique in Scrum and Extreme Programming teams worldwide.

04Concept

What is planning poker?

Invented

2002

By James Grenning

Default scale

1·2·3·5·8·13·21

Fibonacci story points

Used in

Scrum & XP

Most-adopted estimation technique

Planning poker is a consensus-based estimation technique for agile teams. Each team member privately picks a card with their estimate; everyone reveals at once; if estimates differ, the team discusses the gap and re-votes.

Why it works

The simultaneous reveal eliminates anchoring on the loudest voice — the single largest source of estimation error in software projects.

The technique was invented by James Grenning in 2002 as a faster alternative to Wideband Delphi (Boehm, Software Engineering Economics, 1981), and popularised by Mike Cohn in his 2005 book Agile Estimating and Planning. Most teams estimate in story points using a Fibonacci-like scale — the widening gaps mirror a real property of estimation: the larger the work, the less precise any single number can be.

Read the complete planning poker guide

History, why it works, estimation scales, common pitfalls — the full reference.

05Get started

Ready to estimate?

Paste your backlog at the top of this page and share the room link. No sign-up. Free forever.