← Back to blog

Time zones and agile estimates

remote estimates timezones

When your team is in Sao Paulo, Lisbon, and Bangalore, in-person Planning Poker is off the table. And even remote synchronous sessions can mean someone dialing in at 10 PM. So how do you estimate fairly and effectively?

The challenges of multiple time zones

Overlap window

With widely spread time zones, the window where everyone is online at the same time can be as narrow as 1–2 hours. Spending all of it on estimation is expensive.

Unequal participation

Members joining outside their normal hours are more tired, less engaged, and contribute less to discussions.

Different work rhythms

While one member is in “deep focus” mode in the morning, another is in “meetings” mode in the afternoon. Aligning these rhythms is tough.

Multi-timezone estimation strategies

1. Asynchronous by default

Use a Planning Poker tool that supports async voting:

  • PO publishes items with a 24-hour voting deadline
  • Each member votes during their own working hours
  • The system reveals votes once everyone has voted or the deadline passes
  • Synchronous discussion only for items with high divergence

2. Rotating schedule

If synchronous sessions are necessary, rotate the time to distribute the burden:

  • Sprint A: 2 PM BRT (morning in Lisbon, evening in India)
  • Sprint B: 9 AM BRT (afternoon in Lisbon, early morning in India)
  • Sprint C: 11 AM BRT (afternoon in Lisbon, late afternoon in India)

Nobody should always be the one making the sacrifice.

3. Representatives per time zone

Each time zone elects a representative who joins the main session and gathers input from the local subgroup beforehand.

4. Domain-based estimation

Split items by technical domain:

  • Backend items are estimated mainly by the India team
  • Frontend items by the Brazil team
  • Cross-cutting items are discussed in a joint session

Other members can vote asynchronously to validate.

Helpful tools

  • Dev in Poker: async voting support with history tracking
  • Loom/recordings: PO records item explanations for those who can’t attend live
  • Slack threads: structured estimation discussions

Good practices

Impeccable documentation

When members can’t make the synchronous session, item descriptions need to be self-sufficient.

Generous deadlines

Allow at least 24 hours for async voting, considering that someone may be on a non-working day.

Respect personal hours

Never expect anyone to join a meeting before 8 AM or after 7 PM in their local time.

Recordings

Always record synchronous sessions for those who cannot attend.

Conclusion

Multi-timezone teams need more asynchronicity and more documentation than co-located ones. The good news: when well managed, they benefit from 12+ hours of continuous productivity and diverse perspectives that improve estimate quality.