BT

Overlapped or Synchronized Sprints?

| by Vikas Hazrati Follow 0 Followers on Dec 30, 2009. Estimated reading time: 3 minutes |

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).

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT