Free Planning Poker
for distributed teams.
Real-time Fibonacci estimation across timezones. No signup, no plugins, unlimited participants. Open a room, paste the URL, and book consensus before the meeting ends.
- 12ms
- p50 latency
- ∞
- participants
- $0
- / forever
- 99.97%
- uptime
What is Planning Poker?
10 min readPlanning poker is a consensus-based estimation technique that agile teams use to size user stories. Each team member privately picks a card representing their estimate — usually from a modified Fibonacci sequence — and everyone reveals at the same time. The spread between low and high estimates becomes the prompt for discussion, not a vote to average.
The technique was popularized by Mike Cohn in the early 2000s as a way to break out of two estimation anti-patterns: a single loud voice anchors the number, and the team defaults to safe consensus without surfacing real disagreement. Private voting followed by simultaneous reveal solves both in one motion.
Why it works for remote teams.
In a co-located room, body language, side chatter, and eye contact carry a lot of the estimation signal. Remote and distributed teams lose most of that — which is why unstructured remote estimation often turns into one senior engineer saying a number and everyone else nodding. Planning poker gives every remote participant an equal, private, low-friction way to surface their estimate before the group conversation starts.
The other remote-specific benefit is time-zone flexibility. When your team spans APAC, EU, and the Americas, live estimation calls can be painful. Planning poker works just as well asynchronously: share the room URL, leave it open for a day, and let each teammate vote when their working hours overlap with the active story. The team resolves outliers in a shorter sync call afterward instead of spending an hour on the initial votes themselves.
If you are just starting with agile estimation, our guide on what planning poker is and when to use it walks through the fundamentals in more depth.
How it works.
04 steps- 01
Create a room and copy the link
Start a room from the form above and you get a unique URL. The URL is the entire invite — no seat counts, no email forms, no license keys to distribute to your distributed teammates.
- 02
Drop the link into your team channel
Paste into Slack, Microsoft Teams, Discord, or whichever channel your remote team already uses. Teammates click in from any browser, any device, any time zone.
- 03
Add the story you are estimating
Write the story title and start voting. Everyone in the room sees the active story update in real time — important for remote sessions where attention can drift.
- 04
Vote privately, reveal together
Each person selects a Fibonacci card without seeing the others. When the whole room has voted, hit reveal. Discuss any large gaps (a 3 next to a 13 is where the good conversations happen) and re-vote if needed.
Across timezones.
One overlap-hour call
Book a 45-minute window during the overlap hour (for APAC↔EU this is typically 06:00–08:00 UTC; for EU↔Americas it is 14:00–16:00 UTC). Share the room URL in the calendar invite. Estimate 8–12 stories per session; if your backlog is deeper than that, split into two sessions rather than extending the call.
Open for 24 hours
Open the room at the start of a 24-hour window. Each teammate votes from their own working hours as the story becomes relevant. Hold a 15-minute sync only for stories where votes were far apart. Saves about three hours of meeting time per sprint for a team spanning more than eight hours of timezone difference.
Fibonacci values.
11 levelsThe standard modified Fibonacci sequence. Gaps widen at the top by design — a 40 or 100 isn't precise, it's a signal that the story should be split before estimation.
Already done or trivial — nothing left to build.
A few minutes of work. Safe to pick up mid-sprint.
Small, well-understood. One developer, a few hours.
Still small but with a twist — maybe a tricky edge case.
A typical story. Takes most of a day, may need review.
Meaningful work. Possibly needs splitting before pulling in.
Large. Usually signals the story should be broken down.
Too big for a sprint. Split it before committing.
Epic territory. Needs design and decomposition work first.
Unknown magnitude. Return to discovery before planning.
Not enough context to estimate. Ask a question.
Best practices.
7 entriesMake cameras optional
Enforced cameras create video-fatigue for distributed teams spanning many hours. Because planning poker captures every vote explicitly, you do not need visual attendance signals — a missing vote is the signal.
Ban anchoring in the session prompt
The facilitator should read the story title and any acceptance criteria without also saying "I think this is a 5." The whole point of simultaneous reveal is that the first number spoken is everyone's private estimate, not yours.
Time-box each story to under 3 minutes
A full remote session should fit in 45 minutes. If a story pulls more than 3 minutes of discussion, park it — that usually means the story needs to go back to refinement rather than be estimated.
Let outliers explain before re-voting
When someone votes a 13 next to the team's 3s, they see a risk the rest of the team has not. Giving them 60 seconds to explain surfaces edge cases the team would otherwise discover in production.
Use "?" generously across time zones
If a teammate in a different region lacks context on a story, "?" is the right vote. It keeps them from abstaining and flags that the story needs more write-up before a distributed team can commit to it.
Handle mid-vote disconnects gracefully
Remote networks drop. If a teammate disconnects during a vote, either wait one minute for them to rejoin (rooms persist, so they can reopen the link) or reveal and make a note to re-estimate with them on the next call.
Record the final number somewhere outside the tool
This tool is a real-time voting surface, not a long-term story-tracking system. Copy the agreed estimate into Jira, Linear, or whatever your team uses — rooms are designed to be disposable.
Looking for a deeper read? Our remote planning poker playbook covers facilitation patterns for teams that have been distributed for more than a year. If async ceremonies are a broader challenge for your team, the async standup guide covers the same principles applied to daily syncs.
Planning Poker FAQ.
5 entries01Can I use this planning poker tool for async or distributed teams?
Yes. Rooms stay live as long as you want, so teammates in different time zones can vote asynchronously. For sync sessions, share the room URL and vote together on a call. Either pattern works with the same tool.
02Do remote participants need an account?
No. There is no signup, login, or email required. Participants open the room URL, enter a display name, and start voting. Works well for external collaborators, contractors, and anyone who joins only occasionally.
03How many distributed team members can vote at once?
There is no participant limit. Rooms handle entire scrum teams, multiple squads for PI planning, or larger estimation sessions without degradation.
04What cards and values does this planning poker tool use?
The standard modified Fibonacci sequence used by most agile teams: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ? for uncertainty. The non-linear gaps at the top prevent false precision on large stories.
05Does it work on mobile and with spotty internet?
Yes. The tool runs in any modern browser on mobile or desktop and automatically reconnects if the connection drops — teammates can rejoin the same room without losing their place.