Skip to main content

Sprint Event Schedule for Distributed Teams with Timezone Differences

Last post 02:44 am September 19, 2019 by Daniel Wilhite
6 replies
06:09 am September 16, 2019

I'm currently working with teams that are composed of people from different parts of the world (with different timezones).

Does this mean we have to adjust our working hours atleast during the first and the last day of our Sprints to do the events (assuming we have the Sprint Review and Sprint Planning on the first and the last day, respectively)?


06:34 am September 16, 2019

How do team members usually collaborate with each other throughout each working day?


02:34 pm September 16, 2019

What @Ian Mitchell said and what do the teams think would be the best way to do this?  Also, have you asked the stakeholders what would work for them in the case of the Review?


11:48 am September 17, 2019

The Scrum Guide doesn't say anything about this, and next to that, you don't HAVE to do anything. What does your team think is most pragmatic?


06:18 am September 18, 2019

@Ian Mitchell we have our Daily Scrum everyday and everyone attends it. People use communicating tools since physical communication is not possible.

@Daniel Wilhite the team's current process exists only because things have been like that when people came in.

@Sander Dur but the Scrum Guide says that Sprint Review happens at the end of the Sprint, followed by the Sprint Retrospective prior to the next Sprint Planning.


11:52 am September 18, 2019

Indeed. Than what would the team think is most convenient? 


02:44 am September 19, 2019

So, if the process has existed prior to them team coming together shouldn't the current team has some say in how things should occur now?  The core concept of agile processes is the continuous inspection and adaption based on the information available now.  The current team should be allowed to determine what works best for them, not be expected to operate based on what worked for previous teams.  I guarantee that a lot has been learned since the previous team was doing the work. And the current team has a whole different set of knowledge on which to draw for their own decisions. Even if the stakeholders have been consistent, I would expect that they have learned a lot about how their interactions and information can be useful.

Do not try to make decisions for them team that is doing the work.  Let them decide what works best.  Don't try to make decisions for the stakeholders. Let them decide what works best for them to be able to interact effectively with the Scrum Team.  You should facilitate all of this discussion. Help them to realize that by providing input/feedback it will only make things better for everyone.

Notice that @Ian Mitchell, @Sander Dur and myself all are saying basically the same thing.  If the team isn't involved in any decision made, then the wrong decision is being made. Only the people doing the work can decide what works best. In this case, the Scrum Team and Stakeholders are the ones doing the work.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.