Heartbeat across time zones - timing between sprint events.

It's highly unlikely that you can't implement the ordering of events as described in the Scrum Guide. It's far more likely that the key stakeholders are unwilling to make the broader changes necessary to support the teams.

The ordering of events - Sprint Review, Sprint Retrospective, Sprint Planning - is key to how the team adapts to a changing environment. The Sprint Review is the prescribed opportunity for the Scrum Team and the key stakeholders to come together and understand progress and changes in each others' environments, coming to a shared understanding of reality and updating the Product Backlog to reflect that reality. Once the team and key stakeholders are aligned, the team can reflect on their ways of working and optimize how they work to deliver value to the stakeholders. With this new understanding of reality and optimized way of working, the team can plan their next Sprint.

Having the events in another order, like Sprint Retrospective followed by Sprint Planning followed by the Sprint Review does not put the team in a position to be successful. How can you hold a valuable retrospective unless you get feedback on the product and team's progress from key stakeholders? How can you plan without updating the Product Backlog based on feedback and updated goals? Any feedback and changes to the Product Backlog will be delayed if you hold events in the order that you describe.

Work with the key stakeholders to help them understand the purpose of each Scrum event and how it supports the team's journey toward agility. It may also be beneficial to make sure that they understand the value in agility, especially how the teams can be more responsive to changes in the stakeholders' environment. This falls squarely into the responsibilities and accountabilities of the Scrum Master.

I'd also say that the "no break between Sprints" concept is often misunderstood. If you hold your Sprint Review on a Friday morning and your Sprint Retrospective in the afternoon and there aren't enough working hours to hold your Sprint Planning, it should be on Monday. The purpose of the continuous Sprints is to avoid situations where the team holds a Sprint Review and Sprint Retrospective and then waits days for the next Sprint Planning, where those days may be filled with overhead work or work outside of a Sprint context. Any discussion of scheduling needs to consider how long the events are and ensuring that the team is working at a sustainable pace, avoiding exhaustion and burnout.

I am going add to @Thomas Owens' excellent response that no where in the Scrum Guide does it state anything about working hours.  Theoretically the next Sprint starts when the previous ends.  Reality means the next Sprint starts in the immediate working hours of the team after the previous Sprint ends during the working hours of the team. 

We're even doing things slightly out of order due to stakeholders' scheduling.

Why do stakeholders call the shots on how the team implements its own Scrum process?

Scrum is very good at exposing constraints quickly. The challenge often lies in interpreting the things we see with this new transparency, and the problem you describe is rather unlikely to be one of timing.

Why do stakeholders call the shots on how the team implements its own Scrum process?

Because the scrum guide says a sprint review is when "...The Scrum Team presents the results of their work to key stakeholders".  That's a bit difficult to do without them.

Theoretically the next Sprint starts when the previous ends. 

Retrospectives mark the end of a sprint, Sprint planning marks the beginning of the next.  I understand that they should be done as close to each other as possible, but the rigidity of the guidance not to do it the next (business) day seems  severe.  I like @Thomas Owen's explanation/interpretation.



I'll see what I can do about the ordering, but its been difficult to communicate with the external stakeholders.  So far their feedback hasn't impacted the current sprint goal; just helps to update the backlog.

Because the scrum guide says a sprint review is when "...The Scrum Team presents the results of their work to key stakeholders".  That's a bit difficult to do without them.

I'd suggest that's precisely the reason why they ought to be there, instead of changing Scrum to suit them. It isn't a matter of timing. There's an organizational gravity to be overcome, and the results that are to be obtained from implementing Scrum depend on it.

Even if you can't have the Stakeholders at any other time that one specific moment, you can organize your team around that availability. Sprints do not need to be Monday - Friday, you can do the Review whenever the Stakeholders are available (if that is stable!), and have Retrospective and Planning with that as guide.

Good evening, 

Your response was very helpful Thomas. I am wondering what you would do in this situation. I have a team of about 7. The majority are in Spain/Russia/UK. A few are in the Eastern US. This leaves us with a 3 hour window of overlap to hold our meetings. How would you go about scheduling the Review, Retro, and Planning, to maximize success and productivity, while minimizing downtime? We have a few ideas, but can't seem to get the order of Review, Retro, and Planning such that it isn't causing a large amount of downtime in some way. 

If we do the Review and Retro one day, and the Sprint Planning the next, we've got about 5 working  hours for the US people before a new Sprint would start, and about 6-7 for the International people. If we do the Retro and Planning one day and the Review the next, we won't be able to take the stakeholder feedback and put items into action in the next sprint. 

Any thoughts would be greatly appreciated.

Thank you!

If we do the Review and Retro one day, and the Sprint Planning the next, we've got about 5 working  hours for the US people before a new Sprint would start, and about 6-7 for the International people.

If there is a 'gap' in time between the end-of-sprint events and Sprint Planning, is there trust within your organization that the Scrum Team will be productive during that time?   Activities like refinement, cross-training, knowledge transfer, and personal training/learning are just a few that come to mind.



Keep in mind that optimizing utilization is not the goal, but adhering to the proper cadence is.

is there trust within your organization that the Scrum Team will be productive during that time?

That's the key point. Have the team self-organized with members across these time zones? Have they decided it's the best arrangement under the circumstances? Are they empowered to make these decisions?

If they aren't, who is calling the shots, and upon what is trust founded?

Your response was very helpful Thomas. I am wondering what you would do in this situation. I have a team of about 7. The majority are in Spain/Russia/UK. A few are in the Eastern US. This leaves us with a 3 hour window of overlap to hold our meetings. How would you go about scheduling the Review, Retro, and Planning, to maximize success and productivity, while minimizing downtime? We have a few ideas, but can't seem to get the order of Review, Retro, and Planning such that it isn't causing a large amount of downtime in some way.

I don't believe that having such small amount of overlap is conducive to having an effective Scrum Team. Even with a 1-week Sprint and considering that events are "usually shorter" than their maximum timebox with shorter Sprints, you'd need to use three days for these events to have the whole Scrum Team together and actively participating. Since the events are described as opportunities for the Scrum Team (and, in the case of the Sprint Review, key stakeholders) to come together, I don't think it would be consistent with Scrum to find asynchronous ways to hold the events.

This doesn't mean that there's not a way to work in this type of environment. There are open-source projects that function with a globally distributed group of developers. I would look toward a state of continuous flow rather than the timeboxed iterations of Scrum. You have 3 hours of overlap to use for some combination of meeting with stakeholders to assess progress, inspecting the process, and refining/ordering the backlog of work, as needed. There may or may not be strict cadences. The most likely opportunity for a strict cadence would be involving the external stakeholders, since they may have additional demands on their time beyond the work the team is doing.