Scaled Scrum Review Meeting Methods

But from stakeholders we have got a feedback about improvement of our sprint reviews. Each team has 20 mins for their demos and presentations.

What does the team think of this feedback? Is it not up to them to decide what to do with the feedback, and how and how long they want / need?



If you really want to go overboard, don't let tht team prepare anything and simply let them ask PO and stakeholders what they want to see the next 20 minuten ;)

You refer to "Sprint Reviews" - does this imply that each team holds its own Sprint Review?

I would look towards scaled Scrum frameworks such as Nexus and LeSS for ideas.

Although I've found that giving teams a chance to perform an internal review in preparation for the broader, cross-team review is helpful to align internally before including external stakeholders, the Sprint Review should be a single event that is aligned to the product.

I'd also look at how you divide time. This goes back to having alignment at the product. Instead of dividing the Sprint Review into time segments by team, the event can be structured to tell a story about what was done and ready for delivery and how this impacts users, even if this cuts across team boundaries.

I'd want to make sure that different stakeholders are having their needs met. When you have multiple teams working on a single product, there's a need to get into technical details about the work done by each team, but this probably isn't of interest to external stakeholders.

Could you please suggest me a review method for 6 different scrum teams? Our PO's and stakeholders also attend our sprint reviews.

Why would 6 different teams have the same Sprint Review method? There are multiple Product Owners, and so it would seem, more than one product.

Hi,

@Ian yes actually we have 2 different product. But stakeholders wants to see all the outcomes in a single sprint review meetings. As a result (unfortunately) we are losing our focus. Maybe we can discuss about separating two different product review meeting. 

One idea is to think of a Sprint Review with external stakeholders as a "product release" meeting.   Treat it as if you're discussing the newest version of the product, even if what is being delivered crosses multiple teams.

Customers don't really care about who worked on what.   They care about functionality, and what the latest features are.   Focusing on that will keep their interest.

@Ian yes actually we have 2 different product. But stakeholders wants to see all the outcomes in a single sprint review meetings. As a result (unfortunately) we are losing our focus. Maybe we can discuss about separating two different product review meeting. 

Your Sprint Reviews should be focused around each product. But that doesn't mean that you can't adjust your scheduling into two distinct timeblocks that are back-to-back that seem like a single meeting to your external stakeholders.

Hi @Timothy

We have just focused on the value and we decided to talk about features that we have been developed. And the last sprint review is good and serve the real purpose of the review meeting:)

Thanks to all!