Async Planning Poker: How to Estimate Across Time Zones Without Midnight Calls

Async planning poker means team members read stories, ask questions, and cast hidden estimates on their own schedule inside a fixed window (usually 24 to 48 hours), then the team meets briefly only for the stories where votes disagreed. You keep the two things that make planning poker work, independent estimates and a discussion of the spread, without dragging anyone onto a call at 11pm.

This guide gives you a concrete cadence, a worked time-zone overlap table, a rule for which stories should stay synchronous, and reminder messages you can paste into your team chat.

Why sync planning poker breaks across time zones

Planning poker depends on everyone estimating independently and revealing at the same moment. That protects against anchoring, the effect Kahneman and Tversky described where the first number you hear pulls your own judgment toward it. Across eight or more hours of time difference, keeping that ritual synchronous causes predictable damage:

• Someone always joins at the edge of their day, tired and quiet. Their estimate, often the one from the person who will actually build the thing, is the weakest one in the room.
• The inconvenient slot tends to land on the same region every time, usually whoever is furthest from headquarters. People notice.
• People skip. When the offshore half of the team stops attending, estimation turns into "the US team sizes it, India builds it," and the knowledge gap shows up mid-sprint.
• It adds yet another video call. Stanford researcher Jeremy Bailenson's work on "Zoom fatigue" points to constant close-up eye contact, staring at your own image, reduced movement, and the extra effort of reading cues over video. A two-hour refinement call after a day of meetings hits all four.

Async estimation addresses all of these, but only if it has structure. Without structure it turns into a spreadsheet where people type numbers next to each other's numbers, and you lose the independence that made the exercise worth doing.

Step 1: Map your overlap windows

Before picking a cadence, write down when people are actually working at the same time. Here is a worked example for a team in New York, London, and Bangalore, assuming 9:00 to 17:00 local hours during US/UK summer time (EDT is UTC-4, BST is UTC+1, IST is UTC+5:30):

The least painful all-hands slot is a stretch at both ends: 12:00 UTC = 8:00am New York, 1:00pm London, 5:30pm Bangalore. Thirty minutes there is tolerable once a sprint. Two hours every week is not.

Two things this table tells you:

1. Async isn't optional for this team. No core-hours window covers everyone, so any fully synchronous ceremony puts someone outside their working day.
2. London is your relay. London overlaps with both other sites, so a London-based PO or tech lead can answer questions from both sides within the same day. If nobody is in a bridging time zone, plan for a full 24-hour turnaround on questions.

Redo the table when clocks change. The US and Europe switch daylight saving on different weekends and India doesn't switch at all, so overlaps move by an hour twice a year.

Step 2: Run a 48-hour async estimation cadence

This is the default cycle for a batch of 8 to 15 refined stories. Every step boundary falls at 12:00 UTC, so each site gets a full working day inside every phase.

Total individual effort is usually well under an hour spread across three days. Elapsed time is two to three days, which is why async estimation suits backlog refinement a sprint ahead rather than just-in-time sizing.

The 24-hour compressed version

For small batches (3 to 5 stories) or a team with real overlap, merge Ask and Vote into one 24-hour window. People ask questions first and vote once they're answered. Reveal at the same UTC time the next day. Expect more spreads, because some people will vote before late answers arrive.

How to keep votes blind for 24 to 48 hours

This is the part most teams get wrong. If people can see earlier votes, later voters anchor on them, and that independence was the whole reason for the exercise. Options:

• A form that hides responses. A Google or Microsoft form where only the facilitator sees responses. Columns: story key, estimate, confidence, one-line reason.
• Direct messages to the facilitator. Fine for teams up to about six people.
• A planning poker room, for a short window. Most tools reveal at a deadline or when everyone has voted. Alignlee is different, and you should know how before you rely on it for async. Its rooms last 24 hours (the same browser rejoins automatically), and votes reveal automatically once 50% of the voters currently in the room have voted. That makes it a good fit for a short async window where everyone joins at the start, like the overlap call above or a same-day window for a two-site team. It's not a fit for a 48-hour blind vote where people trickle in one at a time, because the first few votes would trigger the reveal. For multi-day windows, collect votes in a form and use the room for the Resolve call.

When a spread needs discussion

Use one simple, published rule so nobody argues about it:

• On a Fibonacci deck, flag the story if the highest and lowest votes are more than one card apart (3 and 5 are fine; 3 and 8 need a conversation).
• Flag it if anyone voted "?".
• Flag it if anyone wrote "unsure" or gave a confidence below about 40%.

Everything else takes the most common value, or the median if there's no clear mode. Write down the reasoning from the vote form, because six months from now someone will ask why it was a 5.

Step 3: Decide which stories stay synchronous

Some stories shouldn't go through async at all. Triage at Post time:

On a mature team with a well-refined backlog, most stories end up in the async column. Early on, or in a messy domain, expect the reverse. That's not a failure. It tells you the stories aren't ready, and the backlog readiness checklist is the fix.

Step 4: Write stories that survive async

In a live session, "does this include the mobile view?" gets answered in ten seconds. Async, the same question can cost a day. Every story posted for async estimation should answer these before anyone asks:

• Why: the user or business outcome, in one or two sentences.
• Acceptance criteria: testable, with an example of the edge case that matters.
• Out of scope: what this story deliberately does not include. This line prevents more spreads than any other.
• Known unknowns: "We don't know yet whether the vendor API paginates."
• Reference: "Similar to PAY-212, which we called a 5."
• Dependencies: other tickets, teams, approvals.

If the PO can't write the story clearly enough for someone eight hours away to estimate it, it isn't ready to estimate.

Reminder templates (copy and paste)

Async estimation fails quietly when people forget. A planning poker tool can't fix that for you, and Alignlee has no Slack or Teams integration, so these are messages you send yourself. Schedule them with your chat tool's "send later" option so they land during each person's working hours.

Kickoff (at Post):

Estimation batch for Sprint 24 is up: 9 stories in the refinement board. Questions open until Tue 12:00 UTC (8am NY / 1pm London / 5:30pm Bangalore). Blind voting runs Tue 12:00 to Wed 12:00 UTC using the form linked in each story. Please ask questions in the story's thread, not in DMs, so everyone sees the answer.

Voting open (at Ask close):

Questions are closed and answers are posted. Voting is open until Wed 12:00 UTC. It takes about 15 minutes: estimate plus one line of reasoning per story. Use "?" if a story still isn't clear to you. That's useful information, not a failure.

Gentle nudge (about halfway through voting), sent privately:

Hi Priya, quick nudge: estimation closes Wed 12:00 UTC (5:30pm your time). Form link: [link]. If you're swamped, vote on the three payment stories first since you know that code best.

Last call (a few hours before close, in the channel):

Last call: voting closes in 3 hours. We have 6 of 8 votes. We'll reveal at 12:00 UTC with whatever is in.

Resolve call invite (after reveal):

7 of 9 stories agreed and are final (see thread). Two need a conversation: PAY-301 (votes 3 to 13) and PAY-305 (two "?"). 30 minutes Thu 12:00 UTC. If you can't make it, add your reasoning to the thread by Wed 20:00 UTC and we'll read it out.

Keep nudges private and the last call public. Never name people who haven't voted in a channel.

The Resolve call: 30 minutes, outliers only

Use the remote planning poker format for the sync part, but only for flagged stories:

1. Two minutes of warm-up. Ask one quick question so people in the stretch slot get a chance to speak once before the hard part.
2. Per story, five minutes maximum. The facilitator reads the spread aloud: "We had 3, 5, 5, 13." Then ask the extremes, low first: "Sam, you said 3. What are you assuming we don't have to do?" Then high: "Ana, what's in your 13 that the rest of us might be missing?"
3. Re-vote immediately and blind. This is where a live room helps: everyone is present, so a 50%-reveal tool works fine.
4. If it still doesn't converge in five minutes, stop. It needs a spike or a split, not another round. See estimating large epics for how to split it.
5. Record the reasoning in the story, not just the number.

Rotate the slot each sprint. If you use 12:00 UTC this sprint, consider 07:00 UTC (8am London, 12:30pm Bangalore) next sprint, with New York reading the notes and adding comments afterward. Whoever usually gets the bad slot should get the good one sometimes.

Common mistakes and fixes

For the deeper anchoring problem, see how to stop anchor bias in planning poker. For the cultural side of distributed estimation, such as hierarchy, language, and who feels safe voting high, see offshore and distributed estimation.

FAQ

What is async planning poker?

Async planning poker is planning poker spread over time: team members read stories and submit hidden estimates on their own schedule within a fixed window, usually 24 to 48 hours. All votes are revealed at once, and only stories with a wide spread get discussed, often in a short live call. It keeps independent estimation without needing everyone online at the same time.

How do you do planning poker across time zones?

Map your overlap windows in UTC first, then set every deadline at a single UTC time that falls inside everyone's working day at least once. Collect votes blind (a form with hidden responses works), reveal them together, and hold a short sync call only for the outliers, rotating its time each sprint. If no overlap exists at all, run the outlier discussion in writing too.

Is asynchronous story pointing as accurate as a live session?

It can be, as long as the stories are well written and the votes stay hidden until reveal. You lose the instant clarifying question, so story quality matters more. You gain estimates from people who are awake and had time to think, which often includes the engineers who'll actually do the work.

Does async estimation help with Zoom fatigue in Scrum?

Yes. Replacing a weekly two-hour refinement call with a 48-hour async window plus a 30-minute outlier call cuts video time sharply, and people can estimate when they're fresh instead of at the end of a meeting-heavy day. Keep one short live touchpoint per sprint so the team still talks.

Which planning poker tools support async estimation?

Behavior varies, so check exactly when each tool reveals votes. Alignlee is free and needs no signup. Its rooms last 24 hours and reveal once half of the voters in the room have voted, so it suits short async windows and the live outlier call. For multi-day blind voting, a form with hidden responses is the simplest reliable option.