If a scrum master is handling multiple parallel sprints, should the sprints be synchronized?

Question

We are looking into adopting Scrum and would want our Scrum Masters to be able to handle 3~4 parallel Sprints. These parallel sprints can be for a single product or unrelated products. Is it a better practice to start the parallel sprints 1~2 days appart or have a wider gap than that.

Answer 1

We have used scrum teams that work on different modules in the same project.

In our case we start the sprints on the same day for all teams. We also have some of the standard meetings as joint meetings with all team members, for example the retrospective.

If we did not do it like this we would get two problems:

• More difficult to coordinate work / dependencies between the teams
• The team that started first may determine what the other teams need to work on

Answer 2

I think the scrum master will be most important and demanded during sprint planning and review/retrospective meetings (especially when starting with SCRUM).

These meetings might be a little bit strenous and long (especially the first few sprints). So you should schedule your sprints in a way the scrum master can handle.

Answer 3

Generally Speaking there is no rule. If the Sprint are related to each other, means the teams are pulling out of the same Product Backlog, than the Sprints must be synchronized, so the only way out is to have a single Sprint Planning Meeting, and one Scrum Master (depending on the number of teams may not be such an easy job ;-) ).

You will have a problem though by the Team Retrospective, there you need to off-set the meetings, or a single Scrum Master won't be able to moderate both of them :-)

If you run on unrelated projects, with multiple teams, than I normally suggest to off-set the Sprints so that not only the Scrum Master, but also all the other "high profile" resources, and the infrastructures (deploy, build time, meeting rooms...) can be better used and planned :-)

HTH
Best
ANdreaT

Answer 4

If you're running multiple teams, I have found it best to have a Scrum Master for each team, and a Product Owner for each team. Otherwise, as others have pointed out, you should stagger the sprint start/end dates so the Scrum Master and Product Owner can be fully available at the sprint planning, review, and retrospective meetings.

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. (My real preference is to have the same team work on all dependent user stories for a feature, but this is not always practical.) The Product Owner Council can have their own administrative work backlog, e.g., groom the backlog for upcoming sprints, reallocate items between team backlogs, etc., and run a Scrum complete with sprint planning, daily standup, sprint reviews (backlogs ready for the next sprint, epics broken down into user stories, acceptance criteria developed, etc.), and retrospectives ("We weren't ready for the next sprints... why not? What do we do to prevent this from happening in the future?").

I have found in practice that a Scrum of Scrums doesn't seem to add much value. I think this practice came from the days when the Scrum Master was driving his Product Owner. I do believe there is value in a Scrum Master Council, but mainly to talk about Scrum-related issues and share best practices. It's far better for team members, the Product Owner, and/or the Scrum Master to attend other teams' daily standups if they want visibility into what is going on inside other teams' sprints... and then to follow the team out of the room and arrange for additional face time if necessary. Meetings really should only be called to make decisions.