Skip to main content

Should multiple scrum teams combine their sprint review

Last post 07:34 pm September 7, 2021 by Ian Mitchell
6 replies
06:53 pm November 30, 2018

We have multiple scrum team with different stakeholders. During our SoS, we had a discussion about having a single sprint review for all the scrum teams and inviting all the stakeholders. I do not agree with this because , this decision should not be taken by Scrum Master. Also , we have different product backlog because each team have their own PO.

I would like to understand if someone see any value combining the reviews.

08:07 pm November 30, 2018

Have you asked those who participated in the discussion what problem they believe this would solve?

09:13 pm November 30, 2018

Are your multiple Scrum Teams working on a single product or multiple products? You say that you have multiple Product Backlogs, but it's unclear if you are delivering one product, a suite or family of related products, or multiple disjoint products.

In cases where you have multiple Scrum Teams working on a single product, the scaling Scrum frameworks that I'm familiar with (Nexus and Large Scale Scrum) suggest a unified Sprint Review. This is because the teams are delivering a common, fully integrated Increment at the end of the Sprint. It makes sense to have the teams (or minimally representatives from all of the teams) and stakeholders present at a single event to review the work done over the Sprint.

However, if you have multiple products, it may not make sense to have everyone present. However, scheduling back-to-back Sprint Reviews in the same time window may make scheduling time with the key stakeholders easier.

03:29 pm December 3, 2018

What was reason that your SoS gave for wanting to do this?  

Personally, I do not see a reason for it unless as @Thomas said, you are doing work that is actually a single product or product suite.  If that is the case, you read up on Nexus, Large Scale Scrum or SaFE to understand how the combined review is explained and purposed. 

The reason I'm against it is because I think it will build into a large scale demo and distract from the purpose of getting feedback from the stakeholders on the future direction for the product backlog.  I can be wrong but that is what I have seen happen when this type of maneuver is attempted.

01:33 pm December 4, 2018

We do this as we have a lot of different products and time zones to cover.  The problem is exactly as Daniel Wilhite says, it just turns into a massive demo where people sit and watch but don't feel like they can ask questions due to the volume of work being shown.

We are currently keeping the combined demo, but then offering a Market Place review after so that people can get hands on with the product and test it.

07:45 pm September 5, 2021

@ian Can you have multiple sprint backlogs for the same product even though you have 1 product backlog?

07:34 pm September 7, 2021

The Nexus Guide says: "A Nexus Sprint Backlog is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams".

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.