Multiple Scrum teams
I have a question related to multiple Scrum teams. How to syncronize them?
They work usually on the same PB and share the common definition of "Done". But what's about the Spint length and the Sprint start? Must multiple teams start and end the Sprints at the same time (syncronically)?
Scrum does not mandate that Sprints must be synchronized. As you have noted, when multiple teams are working on the same product, and are therefore drawing from the same Product Backlog, the emphasis is placed on having a shared Definition of Done.
Yet as a general rule one can reasonably expect Sprints to be synchronized. This is because if they aren't, at least one team's increment will be put in delay, and will therefore depreciate in value before a release can be made. However in the wider scheme of things the waste thus incurred is typically minimal, and there can be valid reasons (e.g. logistical ones) for sprints to be staggered.
If sprints are to be synchronized, it's important to make sure that the reasons for doing so are sound ones. Higher management can be very keen to synchronize sprints...not because they value the elimination of such waste, but rather because they want to encourage "release on cadence". Although this sounds good it is often a smoke-screen for wanting to constrain releases to stage gated boundaries, as opposed to the more agile practice of releasing each sprint or on demand.
Thank you for the detailed answer!
@Jeny: good Question.
@Ian: How could they be synchron- let's take following constallation?
There are 5 Scrum Dev. that work on the same product.
They share DoD , PB List sprint length (i.e. 4 weeks), and Product Owner
The sprint planning meeting is for monthly sprints timeboxed (8 hours / 1 day).
From my point of view there will be bottle neck regarding presence of PO in their planning and review meetings,
I think they must start and end with for example with 1 day delay toeach other:
- Team-1 Sprint Planning on monday
- Team-2 Sprint Planning on Tuesday
- Team-3 Sprint Planning on Wedensday,....
Or a big meeting will be organized which all teams participate for S. Planning and S. Review meetings?
> there will be bottle neck regarding presence of PO in their planning and review meetings
Yes, it's a problem. That's what I mean by "logistical reasons" for staggering sprints. PO availability is one such constraint. Another might be the availability of meeting rooms.
> Or a big meeting will be organized which all teams participate for S. Planning and S. Review meetings?
This is another option. Larman and Vodde have considered it in their work on Large Scale Scrum. See the following PDF:
I won't recommend a PO feeding multiple teams, idle case is ONE, at max Two otherwise he won't be able to do justification his role. Don't treat PO as a Project/Program who can be assigned to multiple teams on partial allocation. Having a same start and end date is good for everyone. Your stakeholders and customer will be happy to get a demo of integrated software demo from all teams.
For multiple teams, one of the items in DoD should be related to Integration of their releasable slice.
And what's about the integration of increments every Sprint (multiple team, the same product)?
Is it mandatory to do it in purpose of inspection by PO? I suppose it is so, but I'm not sure...
the whole concept of scaling Scrum is not part of the Scrum Guide, so there is no "mandatory".
However there are good practices, for a deeper understanding I would also recommend the book "´Practices for scaling lean & agile development" by Larman and Vodde.
To answer your last question: If you have multiple dev teams working on the same Product, it is a good practice to have a common Product Backlog and Definition of Done. This implies they have an integrated increment at the end of each sprint, which means they have to integrate at least every sprint (which will not be enough in practice).
Successful teams manage to integrate continuously. Some have a dedicated integration team as one of the dev teams which passes any defects found to the respective dev team, which has to fix them with highest priority.
Re: the integration of increments - it must be part of team's DoD. For multi team scrum implementation each sprint across teams should be releasable.
> the whole concept of scaling Scrum is not part of the Scrum Guide, so there is no "mandatory".
That's right. However, each team's increment must be potentially releasable. If that means integrating it with other team's work, then that is what has to be done. It's a borderline matter and it does touch on scaling, but on balance I'd say that cross-team integration is in fact mandatory in the Scrum Framework.
> Re: the integration of increments - it must be part of team's DoD. For multi team scrum
> implementation each sprint across teams should be releasable.
For multiple Scrum team's that are working towards a Single Product, it becomes important to minimize the "Intersection Set" of the Items that they pick up. Also, important is how the Stories have been split. A horizontal split of User Stories (UI only, Middle Tier only, DB only etc) will may run into problems. A vertical split of Stories will help each team work on a complete stack from UI to DB and help create apotentially shippable product.
Adoption of Development process that includes focus on Automation of Unit Test and Integration Test will also aide such teams.
Further, if the teams are in different geographies optimum use of electronic tools and communication will have to be planned for smooth execution of Sprint.
As per the open assessment questions, teams dont have to have a shared DoD. Each DoD needs to satisfy the potentially shipable criteria for the integrated work.
With respect to the certification test, what is the 'official' take on Single Projects with multiple teams in relation to the PO. Shouldn't there only be a single PO for the project?
The rule is one product backlog for one product which must be represented by exactly one product owner. In Scrum there is no correlation to "project", which can mean many things. A Sprint might be a project.