# Async Planning Poker for Distributed Teams

By kkrawczyk · Published 2026-07-05 · Updated 2026-07-05
https://pokerbutforplanning.com/guide/async-planning-poker

> **TL;DR — Key takeaways**
>
> - Async planning poker lets team members vote on stories at their own convenience inside a voting window, instead of everyone joining one live meeting.
> - It's the practical answer for teams spread across time zones, where a "quick estimation call" means someone is up at 6 a.m. or 11 p.m.
> - Votes stay hidden until the facilitator reveals them, so the anchoring protection of classic planning poker survives the format change.
> - The trade-off is discussion quality: divergent votes need written context or a short follow-up call to resolve.
> - Keep sync estimation for brand-new teams, ambiguous stories, and high-stakes planning; go async for routine backlog estimation.

Async planning poker is [planning poker](/guide/planning-poker) run over a time window instead of a live meeting: the facilitator opens a room and shares a link, team members vote on stories whenever they're online, and the results are revealed once everyone has voted or the window closes. It keeps the core mechanic — private votes, simultaneous reveal — while removing the requirement that everyone be awake at the same time.

## Why estimate asynchronously?

Async estimation exists because the daily reality of distributed teams makes live estimation expensive. Three pressures push teams toward it:

**Time zones.** A team spanning San Francisco and Warsaw shares roughly one to two workable overlap hours per day — and those hours are contested by standups, 1:1s, and actual collaboration. Spending a shared hour on estimation, an activity that doesn't strictly need simultaneity, is a poor trade.

**Meeting fatigue.** Estimation meetings are long, and most of each meeting is only relevant to a few people at a time. Async voting compresses each person's involvement to the minutes they actually spend reading and voting.

**Deep work preservation.** A calendar hole in mid-afternoon costs more than its duration — context switching in and out of a meeting fragments the day. Voting async lets each person estimate at a natural break point in their own schedule.

## How does async planning poker work?

The async flow mirrors the classic loop, stretched over a window:

1. **The facilitator prepares the stories.** Each story needs enough written context to be estimated without a live Q&A — acceptance criteria, links, and known risks. This up-front writing is the real cost of going async, and also quietly improves your backlog.
2. **Open a room and share the link.** With [poker but for planning](/), this is one click: create a room, pick a deck, send the URL in Slack or the ticket.
3. **Team members join and vote at their convenience.** Each person reads the story, asks questions in a thread if needed, and casts a private vote. Nobody can see anyone else's vote — the anchoring protection of planning poker survives intact.
4. **The facilitator reveals when quorum is reached.** Once everyone (or an agreed quorum) has voted, the facilitator reveals. Converged votes are done; divergent votes move to a discussion thread or a short targeted call with just the outliers.
5. **Re-vote if needed.** After the outliers share what they know, run a second round. Stories that won't converge async are flagged for the next live session — that's a feature, not a failure, because those are exactly the stories that need real discussion.

## Synchronous vs asynchronous estimation

| Dimension | Synchronous (live session) | Asynchronous (voting window) |
|-----------|---------------------------|------------------------------|
| Speed per story | Minutes, all at once | Hours to a day of elapsed time |
| Total person-time | High — everyone attends everything | Low — each person votes in minutes |
| Discussion quality | High-bandwidth, immediate | Written, slower, but documented |
| Time zone friendliness | Poor | Excellent |
| Anchoring protection | Simultaneous reveal | Identical — votes hidden until reveal |
| Meeting load | One more recurring meeting | None |
| Best for | Ambiguous, contested, or high-stakes stories | Routine, well-written backlog items |

## Best practices for async estimation

Async estimation fails in predictable ways — a voting window that never closes, silent outliers, stories too vague to estimate alone. These habits prevent all three:

- **Set an explicit deadline.** "Votes due by Thursday 15:00 UTC" — 24 to 48 hours works for most teams. An open-ended window signals the estimation isn't important, and participation decays accordingly.
- **Require a written comment on outlier votes.** If your vote is the highest or lowest, one or two sentences on why. This substitutes for the outlier discussion a live session gets for free, and it's usually where the hidden dependency or forgotten edge case surfaces.
- **Write stories to be estimated alone.** If a story can't be understood without asking questions live, it isn't ready for async estimation. The bar is the same as the [INVEST criteria](https://en.wikipedia.org/wiki/INVEST_(mnemonic)) — independent, well-scoped, testable.
- **Let the facilitator summarize.** After the reveal, one message: what converged, what didn't, and what happens to the stragglers. Without a visible close, async processes silently die.
- **Escalate divergence to a call, not a thread war.** If a story's votes span the deck and the comments are multiplying, a 10-minute call with the two outliers beats a 40-message thread.

## When should you stay synchronous?

Async is a default, not a religion — some estimation genuinely needs a room. Keep a live session for:

- **New teams.** A team that hasn't calibrated yet — no shared reference stories, no feel for each other's assumptions — builds that calibration much faster with live discussion.
- **Ambiguous or contested stories.** If you can predict the votes will diverge, skip the async round and go straight to conversation.
- **High-stakes planning.** Quarterly commitments and estimates that leadership will treat as promises deserve the bandwidth of a live session.
- **Anything that keeps failing to converge async.** Two async rounds without consensus means the story needs discussion, splitting, or a spike — not a third round.

Deck choice matters slightly more async, too: coarser scales converge with fewer rounds, which matters when each round costs hours of elapsed time. See our comparison of [Fibonacci vs t-shirt sizing](/guide/fibonacci-vs-tshirt-sizing) if you're picking a deck for a distributed team.

## Frequently asked questions

### How long should an async voting window stay open?

24 to 48 hours covers every time zone twice while keeping momentum. Shorter than a full day risks excluding whoever is asleep when the window opens; longer than two days signals low urgency and participation drops. Pick one duration, make it a team norm, and state the deadline in every request.

### How do you reach consensus without a meeting?

Reveal the votes, then handle only the divergence: outlier voters post a short written rationale, everyone re-votes, and most stories converge on the second round. The key insight is that consensus rarely needs a meeting of everyone — it needs an information exchange between the few people who voted differently. Reserve a short call for stories still contested after a written round.

### What if a team member never votes?

Reveal at the deadline with whoever has voted, and treat the quorum rule as explicit team policy — for example, "we reveal with four of six votes." Waiting indefinitely for stragglers kills async estimation faster than anything else. If the same person repeatedly misses windows, that's a 1:1 conversation about workload or buy-in, not a process problem.

### Is async planning poker as accurate as a live session?

For well-written, routine stories, yes — the estimate quality comes from private voting and outlier discussion, both of which survive the async format. Accuracy suffers only on ambiguous stories where high-bandwidth discussion would have surfaced misunderstandings early; route those to a live session and async handles the rest.