Scrum across time zones: overlap, handoffs and fairness

A team in London and a team in Singapore share a product and, at best, a few hours of the same working day. A team spanning San Francisco and Bangalore shares none without someone working at the edge of the night. The Scrum Guide's preference, that events be held at the same time and place, becomes a design problem, and the solutions each cost something. Knowing the costs helps the team choose.

The principle and the problem

The Guide says that, optimally, all events are held at the same time and place to reduce complexity. It also fixes the pattern of the Sprint: planning at the start, a Daily Scrum every working day, the Review and the Retrospective at the end. None of these needs everybody for long, but each needs the right people at once. A time-zone gap puts those requirements under pressure.

The pressure is highest for the events that require conversation: Sprint Planning, where the Developers and the Product Owner negotiate; the Sprint Review, where stakeholders discuss; and the Retrospective, where openness is the point. The Daily Scrum is short but also needs the whole group.

How much overlap do you need?

There is no number in the Guide. Practical experience gives a rough picture.

These are our own guidelines. The aim is to have enough common time for the events and for a meaningful amount of pairing and problem-solving, and to use asynchronous means for the rest.

Running the events

Daily Scrum. Hold it in the overlap. If there is none, consider a written version for some days, with a live conversation at a time that sometimes suits each side. See running the Daily Scrum remotely for the asynchronous variant and its limits.

Sprint Planning. The part that needs conversation, setting the goal and choosing the items, goes into the overlap. The part where the Developers plan how to do the work can be done separately by sub-groups, with a short check at the end. Prepare more: refined items and written questions in advance.

Sprint Review. Choose a time that suits the stakeholders, since they are the scarcest. If they are in a different zone from the team, rotate the inconvenience. Record the session and collect written questions for those who cannot attend, as a supplement and not a substitute.

Retrospective. The most sensitive to time pressure. Use the overlap, with silent writing asynchronously beforehand to save time. See running retrospectives remotely.

Refinement. Asynchronous comments on items, with a short live session for the hardest.

Handoffs

Whenever work crosses a time zone boundary, a handoff happens. Good ones share a few habits.

• Write the state of the work. What is done, what is next, what is blocked, and why. The next person should be able to carry on without asking.
• Record decisions with reasons. The next person cannot ask "why did you choose that?" for another twelve hours.
• Make questions answerable asynchronously. Put the context in the question. "Should the confirmation be sent at payment or when the tutor accepts? Option A has this effect, option B this one. I plan to do A unless you say otherwise by 10:00 your time."
• Use the board as the handoff. Status, owner and notes on the item.
• Close the loop. Say when the handoff is received and understood.

Follow-the-sun

The idea has an appeal: work passes from site to site so that development goes on around the clock. Follow-the-sun development is a form of globally distributed engineering in which a product is owned and advanced by one site and handed off at the end of its day to a site several time zones west. In principle, two sites could provide up to 16 hours of development a day and three sites up to 24, cutting the elapsed time by as much as two thirds.

The documented record is thin. The practice is not commonly applied in industry and has few documented successes, probably because of its demanding requirements, and an early attempt with a team across five sites was reported unsuccessful because daily handoff of software artifacts was not the norm. For a Scrum Team the reasons are clear. Handoffs lose context. Decisions take a day to reach the other site. The team-level self-management that the Guide describes needs conversation, and a relay makes that slow. Most teams find it works better to have each site own its own items end to end, with limited overlap for coordination, than to pass the same item around the clock.

Sharing the burden fairly

Overlap hours always suit some people worse than others. A fair arrangement does three things.

1. Rotate the awkward slot. If the only common time is early for one group and late for the other, alternate weeks.
2. Count the cost. Time worked outside normal hours is recorded and compensated with time off.
3. Limit it. Keep the number of such events down, short and well prepared.

The Guide says that working at a sustainable pace improves focus and consistency. A team that is routinely awake at midnight for a meeting is not at a sustainable pace. The Scrum Master should watch for this.

A worked example

This is an illustrative team of eight: five in Berlin (UTC+1), two in Bangalore (UTC+5:30) and one in Nairobi (UTC+3). The common window is 09:30 to 12:00 Berlin time (14:00 to 16:30 in Bangalore, 11:30 to 14:00 in Nairobi).

The Daily Scrum is at 09:45 Berlin. Planning, the Review and the Retrospective fall on Mondays and Fridays in the window, with a rotating start time of half an hour, so that Bangalore does not always finish late. Refinement happens in writing across the week, with a live session on Wednesday for the two hardest items. Pairing between Berlin and Bangalore is arranged inside the window and solo work is done outside.

At the end of the Sprint, Berlin and Bangalore each write a short handoff note on the board for items that cross. The team agrees that nobody is expected to read messages outside their hours and that urgent matters use a phone call. In the Retrospective after two Sprints, the Bangalore Developers say that decisions made in the Berlin morning chat are the main problem. The team adds the rule that decisions go on the board with their reasons, and delays are cut.

Common mistakes

• Scheduling by the majority's convenience. The minority carries the cost every time.
• Expecting instant replies. Agree response times.
• Skipping the written trail. Zones turn small gaps into days.
• Running the Review with half the audience asleep.
• Treating follow-the-sun as a speed-up. It is more often a slow-down.
• Ignoring local holidays. Plan for them in capacity.

How to practise it

Work out the common hours for everyone in your team and put the events in them for a month, rotating the worst slot. Count how many decisions were made outside the overlap. In the simulator the AI teammates are always available, which makes it a useful contrast with the delays of real distance.