When a Scrum project grows, so do the team members. The suggested way of managing a growing team is to split the team into multiple teams keeping in line with the Agile recommended team sizes. However, there could be multiple communication and coordination problems when each team starts working in a sprint of their own.
Mike Cohn, suggested that the best way to resolve these issues is by synchronizing the sprints. On one such project, he initially started with staggered sprints but soon found out that it was not a good idea. The biggest problem with overlaping sprints was that there was always more than one team which was partly done with their work and hence the system could not be delivered to the customer for either feedback or deployment.
Synchronization does not mean that all the sprints should finish on the same day. He suggested that the synchronized sprints should end within a day or two of each other.
Allowing sprints to end over a two- or three-day period can make it easier for someone on multiple teams to attend all the review and planning meetings expected of someone on multiple teams. Additionally, it has the advantage in many cases of better accommodating remote team members who may travel into town for these meetings.
Mike further added that having synchronized sprints does not mean that different teams cannot have different sprint lengths. Here the teams could go with nested sprints.
The most common use of nested sprints is when the various teams on the project cannot agree on a common sprint length, with some wanting two-week sprints and others wanting four-week sprints.
Responding to Mike, Angry Poodle added that they had to move to synchronized sprints given the complexity of their product.
In our company where the system we build is very large and complex, synchronization is hard. On the other the size of the system forces us to big bang releases that happen 3 times a year (x3=9, for each supported version). The internal chaos around the release sprints is almost too large to be handled. This is why we’ve had to keep the sprints in sync.
Jeff Sutherland however suggested that in many situations overlapping sprints might be a reality.
According to him, there could be simultaneous overlapping sprints running through a set of development teams. He suggested the need of a MetaScrum to deal with multiple sprints. According to him,
To deal with simultaneous weekly and monthly Sprints, along with quarterly major releases, a MetaScrum was formed at PatientKeeper led by the lead Product Owner. Having the entire company driven by a single agenda out of the MetaScrum meeting has dramatically reduced company communication problems, customer angst, general churn, and confusion. Just as the Scrum meeting has consolidated all decision making for a Sprint, the MetaScrum meeting consolidates all decision making for multiple Sprints.
Similar on these lines, responding to a question, John Clifford suggested the formation of a Product Owner Council.
I find that multiple-team projects work well via the use of a Product Owner Council, consisting of a Chief Product Owner who 'owns' the project/release and individual team product owners who help manage their individual team backlogs, etc. Coordination between the teams is done via backlog management, e.g., if Team B needs a user story from Team A, then the Product Owner Council ensures that the user story is completed before the dependent item comes up in Team B's proposed sprint backlog.
Thus, there are situations in which synchronization might not be possible. In such circumstances, MetaScrum or the Product Owner Council could be an option. However, Mike suggested that sprints should be synchorinzed where possible. He drew the following analogy to support his point,
To me the benefit of this is like one of those families with on-the-go parents and kids who say “Do what you have to but everyone is home at 6pm for dinner.” We all go our way during the day (work, practices, friends, whatever) but it all comes together once per day (sprint).