When more than one Scrum Teams works on the same product:
Scrum at Scale
Picture an organisation with 4 products, built by 15 Scrum Teams. All these Scrum Teams know that the Sprint Review is an important event. Every Scrum Team conducts their own Sprint Review and wishes to see the important stakeholders participating. Some of these stakeholders are invited for all these reviews. What are the odds that these stakeholders actually are PRESENT at the reviews?
It’s a simple calculation. Suppose that the reviews take 1.5 hours on average and that the teams have 2 week Sprints. And suppose that that valued stakeholder would participate in all of them. That’s 22.5 hours per 2 weeks, more than 11 hours a week. More than 25% of the stakeholder’s working week. That’s a lot!
But… is it the way that Sprint Reviews are meant to be conducted? Here’s some food for thought:
“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.” — SG
What if… multiple Scrum Teams work on items from the same Product Backlog? There’s more:
“The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;” — SG
If multiple Scrum Teams work on items from the same Product Backlog:
“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.” — SG
… does it make sense to have multiple Sprint Reviews to discuss what Product Backlog Items have been “Done”? Isn’t that a bit repetitive?
Doesn’t it make perfect sense to have ONE Product Owner managing ONE Product Backlog and having ONE Sprint Review per product?
Wouldn’t it make perfect sense that everyone that has been playing a role in development of the product meets to discuss the PBI’s that have been “Done” and inspect and adapt the Product Backlog? I would say so!
It would certainly resolve the issue of the example company. The amount of Sprint Reviews would be reduced from 15 to 4 and the events would carry more weight because the product as a whole is discussed and not only a part of it. It would also maximise the chances of getting the valued stakeholders to participate.
It is exactly how several Scrum scaling frameworks, intended to be lightweight solutions (a.o. Nexus, LeSS), approach the Sprint Review. However I think it would make sense to have one Sprint Review even if you decide not to adopt the whole scaling framework.
Bottom Line
The Sprint Review is often linked directly to the Scrum Teams. Every Scrum Team has it’s own review. However it does make sense to have Sprint Reviews per product/Product Owner/Product Backlog. It would dramatically increase the impact of such an event.
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling
Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!
We run a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts.