Why Organizations Should Have a Product Owner Team
The Product Owner Team
The product owner team is a construct used in many large Agile Transformations to deal with the challenges of the Scrum Product Owner, at scale. However, the specific makeup of the product team is highly dependent on the unique needs of the organization. Therefore, there doesn’t seem to be much consensus around how this team should be implemented. That said—collectively—the people assigned to this team share the role of the Scrum Product Owner.
To understand the role of a Product Owner team, let’s look at the role of Scrum Product Owner:
1. Create the product backlog
2. Prioritize the product backlog
3. Elaborate the requirements
4. Communicate the product vision
5. Represent external stakeholders
6. Participate in Scrum meetings
7. Inspect sprint outcomes
8. Change direction as necessary
9. Communicate progress
10. Terminate the sprint or release
Sometimes More is More
Typically, I might have one person that serves as the primary interface to the team, but we’re recognizing that the PO is a job that sometimes requires more than one person to do well. Considering the product owner team from a slightly different perspective—they serve as an enabler of the Scrum team(s) that the product owner might support.
They’re responsible for translating the needs of the business into user stories that are independent, negotiable, valuable, estimateable, small, and testable.
These user stories are ready to be consumed by the sprint teams with minimal discovery during the course of the sprint. This team is responsible for making the key decisions that the Scrum teams are not empowered to make by themselves… usually decisions where requirements dependencies span Scrum teams or where we have architectural dependencies (cross-cutting concerns) between teams. One of my primary goals in implementing a Product Owner team is to increase clarity and reduce thrashing that often happens in larger, more complex product environments.
I’ve been advocating for Product Owner teams for a few years now. Next post I’ll explore some of the roles and job titles that usually show up on these teams and how they play together on a complex product.
Comments (22)
Declan Whelan
Can’t wait to hear more!
Hank Russell
I have been waiting for someone to write an article about this!
I also believe in Product Owner teams and have seen it at larger organizations where they have multiple Scrum teams grouped into multiple feature areas. The roles I have seen in these teams are: Product Manager, Project Manager, Product Owner and Test Manager. I would love to hear more about your experiences around this e.g. how does the PO team work together (Daily standup, Kanban board,…)? Are the roles and responsibilities strictly defined or can they alternate in performing some tasks depending on workload etc.
Hope to see the followup soon.
Hank
John Peltier
Mike, I like this idea and good writeup. Do you run into problems with accountability, because you don’t have one single wringable neck? Perhaps you’ve written about how you address this within the PO Team? Thanks!
Hey John… yes, you will run into accountability problems. But… organizations with accountability problems have problems with empowering a single product owner to decide unilaterally what goes into the product.
The measure of a well formed PO team is that we have sufficient well groomed backlog. You have to get agreement that the PO team can produce this and hold them accountable for producing it.
Keith Cerny
Great post! We have a PO team in our org and it is nice to see a crisp description of the key responsibilities of the team like this. We have ten scrum teams across multiple locations so we definitely fall into the complex enviroment category. I agree that to manage accountability you need to empower the team which means effectively dividing up the backlog and giving them full ownership. Not an easy task but worth the effort to do. It all centers around the backlog and the PO team have the greatest ability to make it solid.
Mishkin Berteig
Hi Mike, while it is true that many times there is more than one person needed to do some of the aspects of the Product Owner role, I would _strongly_ discourage the use of the word “team” to describe this group of people. It is very very difficult for a single individual to be a member of more than one true high-performance team (read “The Wisdom of Teams”, and many other team books and publications). The Scrum Team really needs the person who is the Product Owner for that team to be fully committed to the Scrum Team… and not have any distraction with membership in any other teams. Of course, the Product Owner for a Scrum Team may belong to other groups and communities within an organization. But calling a group of Product Owners a “team” just doesn’t match with our best understanding of what it takes to make true high-performance teams work. In my Scrum training when I talk about people working at scale, I am always careful to call this group a Product Owner Group, just like you have a ScrumMaster Group in the Scrum-of-Scrums, and you might have a Technical Support Group.
Hope that is helpful!
Hi Mishkin… thanks for taking time out to comment. While I tend to agree with you that people should not be allocated to more than one ‘team’… I think in this case it’s okay. When we coach an organization against matrixing people across multiple teams, the reason is (at least my reason is) that the person has to be able to commit to the team they are on. If we matrix people across multiple teams, they not only have to go to multiple planning meetings, but they often have competing priorities and objectives. My experience is that this is unhealthy and generally an anti-pattern to be avoided. That said, the PO team is different. The PO team’s express intent is to groom the backlog across one or more scrum teams. If the PO team members are not able to support their team (1st priority) AND work with the PO team (2nd priority), this will result in insufficient product backlog to bring into the sprint and impact the velocity of their primary team.
I am in one situation now, where there so little backlog ready to work, that the PO team really is the primary team for many of these folks. I have them in a team room, and their #1 goal is to groom the backlog. I don’t expect this to be the case much longer, but for now… they are a team. The difference between being on a PO team and a regular Scrum team is that the goals of both of these teams are perfectly in sync… neither can be successful without each other. I am willing to have the local Scrum team impacted for the sake of team members creating well groomed backlog for the sprint. If the PO team does not do their job, the Scrum team cannot do theirs.
That’s my take… I respect your opinion on this, just sounds like we might disagree a little.
Martial Delahaye
Mike,
Great article. it really helped me with my current team (this product owner team) appears to be the right solution for us.
Thanks
ps: I wrote a post about it where I reference your :
http://agilebutpragmatic.blogspot.com/2012/03/do-we-need-product-owner-in-team.html
Very cool, thanks for the feedback.
Amol
Thanks Mike for the good read.
Will BA be part of PO group?
Charles Bradley
Mike,
I see that you originally wrote this article back in 2011. The Scrum Product Owner role has changed quite a bit since then, and I’m wondering, if in the new incarnation of the PO role, if you’ve reconsidered the concept of a PO Team as you describe it above at all. I think your years of advocating for PO Teams has helped spur some of those PO role changes.
I’ve recently written an article describing the new version of the PO role, called “The New New Product Owner”. I encourage you to check out the sections entitled “Product Backlog Management Leader” and “One PO Can Do it All!”. I’d be interested in your thoughts on those techniques for helping the PO execute their role well in light of recent changes to Scrum.
Clearly you were onto something with this concept.
Article here:
http://www.scrumcrazy.com/NewPO
My opinion on PO teams has not changed. I think the PO team is the missing construct, that once established, helps dramatically unlock the potential of many agile teams. I’ll take a look at your post, and I’ll see if I can find any source material on how the PO role has officially changed in Scrum. That said, it doesn’t matter to me what the official Scrum Guide says or what Ken and Jeff or Mike Cohn say. I have a TON of respect for those guys, but we are exploring what works in the real companies we work in and don’t feel bound at all by the doctrine of Scrum. As we lead agile into the future, and help large complicated companies adopt agile structures, principles, and practices… we are going to have to look beyond Scrum and the rules of Scrum and invent new things that work. Maintaining backwards compatibility with Scrum isn’t my concern at all. There is a reason I am not a CST and have never sought that designation. I recognize that I am standing on the shoulders of giants, but we have to keep innovating or we are dead. The single PO metaphor does not work at scale in my opinion. It would take a TON of data to convince me otherwise…
Hey Charles, skimmed through your article. There wasn’t anything there that was particularly new to me. Remember, I’ve been experimenting and bastardizing the Scrum notion of a PO for years. All this has been considered. That said, I’m sure your guidance would work in some contexts, but just wouldn’t in some of the ones we deal with. Happy to explore that further with you at some point. All the best. – Mike
Charles Bradley
Hi Mike,
> There wasn’t anything there that was particularly new to me.
That’s disappointing to me as the author. I actually called out one of the changes in the “Scrum History” section that applies directly to an alternative to your PO Team concept, as curated by the Scrum Guide creators(and has proven itself well in contexts like those you describe)…and on that note…
> it doesn’t matter to me what the official Scrum Guide says or what Ken and Jeff or Mike Cohn say. I have a TON of respect for those guys,
I find it interesting that it doesn’t matter to you what people you respect say or think. Especially given that you quoted Jeff Sutherland in your reply to my post on another page. I would suggest that you might be suppressing your own ability to self improve by having an “I don’t care what others say” approach. I’m thinking maybe you didn’t mean what your words actually said.
I’m not going to wade into the CST arguments as I think that they are pretty irrelevant. Having said that, the CST’s and PST’s that are out there might have something to share that could benefit you and your clients. I’m not suggesting a priesthood, just suggesting that maybe you have a blind spot that you should watch out for. I mean this with all due respect and I appreciate your service to our Agile community. I wish you well.
Charles, I’m not sure how to respond to your post. You sound pretty bought into the whole Scrum thing. I wish you the best. We take from Scrum what we need and discard what we don’t. There are lots of different points of view and I’m not interested in anyone’s dogma. We are in the trenches, working to do transformation with real companies, we are not people that do abstract training based on the latest theory… we have a point of view of our own based on our own experience. That point of view is working and has been rewarded in the marketplace. Again, not sure how to respond past that.
Charles Bradley
Fair enough. I would point out that dogma implies that people follow something without knowledge of why they follow it. I can assure you, I know the why, and most thought leaders know the why as well. I encourage you to seek that out too. The journey will benefit you.
See my earlier comment.
Charles Bradley
> We are in the trenches, working to do transformation with real companies, we are not people that do abstract training based on the latest theory…
Everyone that I have mentioned, including Sutherland/Schwaber, leading CST’s and PST’s, Larman/Vodde wrt their Large Scale Agile approach, has real experience, working in the trenches — probably more than you do, especially when you add them all up together. That is why I suggest you at least try to be open minded about the summation of their experiences, as that summation is out there for you to benefit from. (Scrum Guide, the links I shared re: Larman/Vodde, etc)
(I realize that not *all* CST’s and PST’s have as much coaching in the trenches experience as you do, but the leading ones do, and certainly Sutherland/Schwaber do.)
I know I do. I’m like you — we specialize in work in the trenches that are very similar to your contexts– which is the reason I’ve made the suggestions I have(contexts that are similar). Obviously, giving you good advice might help you compete with my company, but I have a higher calling, to help improve the industry. That’s my only goal here, just to give you some ideas for other options. I thank you for taking the time to converse with me here, and again, I wish you well.
Charles… I am done having this conversation with you. If you have ideas that you want to put forward, with an established context, and debate the merit of those ideas in that context once established… I’m fine with that. I’m not interested in resume competitions, I’m not interested in quoting *experts*, I’m not interested in theory. We do what we do and have great success with it. We write about what we are doing because what we are doing is working. Posting to my blog telling me to read some other experts theory is not helpful. Feel free to share your experiences with me if you have first hand knowledge that they work. None of the people you referenced is authoritative to me. They have great ideas. I am sure their ideas have worked for them. I will engage with them directly when appropriate. Again, not interested in proxy debates with you. Happy to talk about approaches you have first hand experience with, as long as you are willing to establish context. No theory.