Async Sprint Planning: Making Estimation Work Across Time Zones
A team split across Europe and Asia can't hold a synchronous planning session that works for everyone. Async estimation is the answer - but it requires a different structure than a live session.
What breaks in async estimation
The core value of planning poker is simultaneous reveal: nobody sees anyone else's vote before submitting their own. In a fully async format, there's a risk that later voters anchor to visible earlier votes. The tooling and process need to protect against this.
The async estimation workflow
Before the session:
- Product Owner writes stories with full acceptance criteria 2 days before estimation opens
- Stories are posted in a shared channel with a "ready for estimation" label
- All team members are given a 48-hour window to vote
During the window:
- Each team member votes independently, without seeing others' votes
- A tool like Play Scrum Poker Online can hold votes in a sealed state until the facilitator reveals
- Team members can add a text comment with their reasoning
After the window:
- Facilitator reviews results; for stories with consensus, estimates are accepted
- For stories with a wide spread, facilitator opens a short threaded discussion (not a meeting)
- A follow-up 24-hour re-vote resolves most remaining disagreements
What still needs a meeting
Not everything can be async. Stories with deep uncertainty or significant design decisions benefit from synchronous discussion. Keep a small weekly touchpoint for these edge cases rather than trying to push everything into async threads.
The hidden benefit of async
Async estimation tends to produce more thoughtful votes. Developers have time to read the full story, check relevant code, and think before committing to a number. This often surfaces risks that would have been missed in a fast-paced live session.
Async estimation isn't a compromise - for globally distributed teams, it often produces better results than a rushed synchronous session at an awkward hour.