Why a Product Owner Team?
Last Updated on Monday, 28 March 2011 04:23 Written by Mike Cottmeyer Monday, 28 March 2011 04:23
The Product Owner Team is a construct used in many larger agile implementations to deal with the challenges of the Scrum Product Owner at scale. The specific makeup of the product team is highly dependent on the unique needs of the organization, and thus 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
While I might have one person that serves as the primary interface to the team, we are 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 (or teams) that the Product Owner might support. They are 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.
Can’t wait to hear more!
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
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.
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.
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.
[...] Product Owner is often brought in to partner with product management as part of the “product owner team” or “product discovery team“. This arrangement usually involves the Product [...]