Project Management

Scale Your Product Owners

From the Taking the Plunge Blog
In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.

About this Blog


Recent Posts

Festina Lente

Everything Old is New Again

What's in Your Project Management Tool Belt?

Scale Your Product Owners

When is a Good Idea a Bad Idea?

Categories: Agile

A few weeks ago, I was fortunate to be able to attend the [email protected] certification course, taught by Jeff Sutherland and Kim Antelo.  There is a lot, from this class, that I could write about, but I'd like to focus on just one topic that I think is critical to effective Scrum, Scrum transformations, and scaling Scrum:  Product Owners.


If you have multiple Scrum teams that are working on different features for the same product, you need to scale your Product Owners.  I'll explain what I mean by that in a moment.


When you take the Certified Scrum Master (CSM) class, you learn the basics of leading an individual Scrum team as the Scrum Master (leading in the sense of a servant leader, not a manager).  When you take the Certified Scrum Product Owner (CSPO) class, you learn the basics of participating on an individual Scrum team as the Product Owner.  Neither class goes in depth into what to do when multiple Scrum teams are working on different features of the same project.   I wouldn't expect them to; it's not the purpose of either class.


You might hear mention of Scrum of Scrums in the CSM class.  If you're not familiar with the concept, a lot of people think of it as a combined standup meeting where a representative from each Scrum team reports on his or her piece of the product.  They don't go into as much detail, and they only bring up blockers that can't be addressed at the team level. 


In [email protected], the Scrum of Scrums is actually what you might call the Team of Teams.  The meeting, described above, is called the Scaled Daily Scrum.  Do you see what is missing?  If you're going to scale your Scrum teams, you need to scale your Product Owners.  Why wouldn't you have a scaled, refined, prioritized backlog, a roadmap that covers the features that each Product Owner is responsible for, and a team of Product Owners that is responsible for these things?  This is called the MetaScrum, and it is sometimes missing when a company is trying to adopt Scrum.  Without this, your Scrum of Scrums, whether you consider it a team or a meeting, will be less effective, which means you won't be delivering value as quickly as you could be.


For more information on the terms I've mentioned and how to scale both Scrum teams and Product Owner teams, please refer to the [email protected] Guide -

Posted on: March 01, 2019 04:17 AM | Permalink

Comments (6)

Please login or join to subscribe to this item
Aaron, thanks for sharing the info regarding the course you recently attended. While I see your point about having multiple product owners and while it is sometimes a necessity, I think it might have a negative effect and things might get lost by having multiple backlogs and multiple product owners. I like the Nexus guide concepts of having an integrated nexus team, multiple development teams and scrum masters but I am more in favor of having one master backlog and one product owner where possible.

Excellent article on understanding of Scrum in multiple team environment. It is very well explained.
Thank you Aaron!!

Rami, I think the key to what you wrote is "where possible." It's not always possible to have one PO for all related teams. You may not need to scale for every product. In [email protected], where needed, you have a chief PO that drives the vision for the product. The POs for the various scrum teams report up to the chief PO and coordinate with each other. I'm oversimplifying, but the point is that when more than one PO is needed is needed, there is still one unifying voice responsible for the overall backlog, roadmap, etc...

I agree with that Aaron - We are on the same page - Cheers !

Dear Aaron
Interesting is your approach to the topic
Thanks for sharing

I think this concept is closely related to the team team concept proposed by Gen. Stanley McChrysta, Tantum Collin and David Silverman in the book Team of Teams: Rules of Engagement for a Complex World

I confess that I need to read the book to delve into the subject and have a sustained opinion

Please Login/Register to leave a comment.