How to manage End of Sprint Ceremonies with multiple team?

How many products are there?

Remember that the key adaptation made in a Sprint Review is to have an up-to-date Product Backlog.

If those 6 teams are supporting one product, then it's not clear who "the POs" are. A Product Owner should be aligned with the product, not a team. Even if only a few of those teams are aligned to the same product and you have multiple products, then the Product Owner should be one person across those teams. This approach of 1 Product Owner per product should go a long way to alleviate the bottleneck among the teams.

Once you have multiple teams working on a single product, it may also be a good idea to start to look at scaling frameworks such as Nexus and LeSS. These frameworks are rooted in Scrum, but provide some additional structures around coordinating multiple teams throughout the Sprint. A product-wide Sprint Review and a two-phase Sprint Planning that starts with a product-wide planning session before the individual teams break off can also reduce some of the bottlenecks that the Product Owner may be experiencing. If done right, the PO may be able to float between each of the team's individual planning sessions as questions arise.

In my experiences, though, refinement becomes even more important in a scaled environment. The ability to detect and attempt to remove dependencies is crucial to preventing teams from being blocked by each other during a Sprint. Both of these frameworks offer some suggestions for improving refinement, as well.

1 Product, 6 Teams, 4 POs.



I know I know......

Separate Ceremonies for each Team.

It's time to challenge the organizational structure since it's not set up for long-term success.

My recommendations:

First, get to 1 Product Owner for the product. If it's a complex product, it's OK to have a team supporting that one Product Owner. Personally, I also prefer to align things like user experience design and business analysis at the product level as part of a group or committee that, to the teams, is represented by a single Product Owner. Having multiple people can help support the individual teams and share the workload, but having one person responsible for owning the product and making the final decision is crucial.

If you to get down to 1 "chief" or "head" Product Owner, you'd have 3 people left. And you have 6 teams. There may be an opportunity to organize the teams such that each of the other 3 "product owners" can work with 2 teams each. That could be a very manageable activity. Of course, this may depend on what your product is how it is organized.

Once you've gotten through the Product Owner role, align the events. When you have multiple teams working on one product with one Product Backlog, you can have at least some of the Sprint Planning, and the whole Sprint Review aligned into one event. Since the teams are coordinating, it also makes sense to have some level of cross-team Sprint Retrospective to identify process improvements that can help across the team boundaries.

Yes I agree completely.

I have been emphasizing this and the use of a PO committee.

As a lowly ScrumMaster in a new organization this is a difficult ask.

Product ownership is unlikely to be managed well by a committee:

• Where there is one product, there ought to be one Product Owner.
• If a nexus of multiple teams is involved in developing a product, the Nexus Framework can be implemented.

The important thing is to establish transparency over team dependencies:

• Once these are visualized they can be understood and managed.
• Dependency management includes issues such as where the PO ought to be, and when.
• Remember there's nothing to stop work from being reviewed continually during a Sprint, and doing so can help to de-risk the Nexus Sprint Review.

Nexus is a good fit however I'm not comfortable bringing it in just yet. 

I may use some of the ideas in Nexus and see if I can convince the Org to take it on.

I do feel I will have to wait some weeks and let them fail first in order to see problems.

If there is one product, aren't the stakeholders the same for each team, and wouldn't each team be interested in knowing what the other is up to?

So the first step to consider would be a combined Sprint Review for all teams at once. If that sounds unhelpful, read what the Scrum Guide says about the Sprint Review, and ask yourself critically whether your Sprint Reviews are really set up to achieve that. You might potentially need to rethink the whole event, so you can maximize learnings from stakeholders, and the sharing of feedback, data, and other insights.

Then in terms of product ownership, I totally agree with what has been said so far. One product, one Product Owner.

Remember that real ownership of a product goes far beyond the work that 1 or 2 teams do for the coming sprints. There are usually far more fundamental decisions that an actual owner of a product needs to be aware of, take a lead on and be accountable for.

Maybe there already is someone in the organization who is behaving like a Product Owner, e.g. a VP of Product.

See this video: How Do You Know You're Really The Scrum Product Owner?

This needn't be doom and gloom for the 4 "Product Owners", but maybe their best fit in a Scrum context is to be a member of the Development Teams, by bringing product management skills into that team. In practice, the work they do might not change, but at least the situation will be more transparent.

Scrum allows the Product Owner to delegate work to each Development Team. The Product Owner remains accountable, but if product management skills exist within the Development Team, this kind of delegation might be easier.

It isn't necessarily an easy problem to solve. Where I work, we have two Product Owners for what is arguably one product, and although we've defined missions and areas of ownership, what we have isn't perfect.

These are almost certainly more important problems to solve than having multiple Scrum events at the same time.

But to then go back to your original point, as a Scrum Master in 3 teams, I relate to it. As teams you may need to decide what is more effective (or less wasteful):

• Set each event at separate times so that the people in multiple teams can attend both (all), or
• Allow those individuals to choose to go where they are most effective

Where I work, we've gone for having all Sprint Retrospectives at the same time, then a debrief where all teams get together and share decisions they've made and actions they plan to take, how these might impact other teams, and where they may need help from each other. Then after a short break, 2 teams go straight into Sprint Planning. The other team accepted the waste of not being able to start planning immediately was worth it, so they wait until later in the day to conduct Sprint Planning with the Product Owner.

Those in multiple teams might mitigate this situation to an extent by the way they communicate with teams prior to the Scrum events. e.g. the Product Owner who attends just one Sprint Retrospective usually shares some insights with the other team, prior to the retrospective.