Is the Product Owner on the Scrum Team?

There’s still some confusion out there about whether the Product Owner is a member of the Scrum Team. Rather than pile on the confusion, please stick to Ken Schwaber’s terms: “Scrum Development Team” for the subset of the team that excludes the Product Owner, and “Scrum Team” for the dev team + Scrum Master + Product Owner. These are defined by _The Enterprise and Scrum_ (Schwaber 2007).

More on this here:

We can debate if/whether/when we need this distinction, but I’d need to hear a pretty convincing reason to make up new terms rather than stick with Ken’s terms.

Related topics:

  1. Should your Product Owner attend your Daily Scrum and the entire Retrospective? Possibly, but I’ve seen cases it impeded self-organization. A Product Owner seeking higher performance through greater self-organization in the long run will ask the development team’s opinion on this.  During Sprint execution, team members report to each other rather than any externally designated leader. This leaves a clearing for leadership to emerge by merit and consent. The Sprint Review meeting is our chance to see how well they kept the promises they made at the Sprint Planning Meeting.  Sometimes — rarely for you, I hope — urgent short-term concerns require a command-and-control intervention. This creates another kind of debt which may or may not be easy to pay off.
  2. Should the Product Owner be highly technical? Usually not, but depends on skills and vision, doesn’t it?  Modern software engineering practices tend to reduce technical dependencies, allowing business people to prioritize by business value and simpler effort estimates without deep technical knowledge. Of course, one reason we’re doing Scrum is to get business people and technical people to learn from each other.  A legacy product steeped in technical debt, where technical dependencies dominate prioritization, will demand a Product Owner with a deeper understanding of the technology (and a technical debt repayment plan).  A “rocket science” project may require a rocket scientist Product Owner.
  3. Should we have multiple delegate (or proxy) POs for multiple teams?  Maybe sometimes, but we’ll regret not tying them to one uber PO. I saw a delegate PO get UNappointed by his chief PO who didn’t get the vision — doing Scrum helped uncover the problem in two weeks.Another time I saw it working fine because the delegate POs were completely in sync with the uber PO.  Another very large Scrum implementation had local proxies on teams who were domain requirements experts with an extremely busy uber PO prioritizing for all of them.  One way or another we need to increase the bandwidth (and reduce latency) between developers and customers.


For a definition of the roles, see the 6-page illustrated Scrum Reference Card. Or watch this entertaining introduction to Scrum video.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
6 comments on “Is the Product Owner on the Scrum Team?
  1. Kevin E. Schlabach says:

    So, by your refinement, the Product owner is a member of the scrum team, and you use a more refined term (Scrum Development Team) for a non-cross-functional subsection of the team. Does the scrum development team include the QA, UI, analyst, UX roles? I guess I’m asking for clarification because I’m worried about the break-down of the cross-functional team idea.

    I’d simply prefer saying “yes, the PO is part of the team” because the PO represents the customer, and the customer should be included in the team.

    The rest of your comments talk about HOW the PO interacts with the team. In topic 1, I believe the PO should be part of daily scrum and other meetings, but they also have to understand the difference between themselves and those making the estimates and commitments. If they can’t understand this, it needs to be addressed and hopefully the option of buffering/removing them from the team interactions is the fall-back option.

    The third topic is an interesting problem, but hopefully this challenge is limited to large enterprise situations.

    Great post.

    Kevin E. Schlabach

  2. Michael James says:

    Kevin wrote:
    I’d simply prefer saying “yes, the PO is part of the team” because the PO represents the customer, and the customer should be included in the team.

    From what I’ve seen, any hint of a boss on the team will limit its self organization. It will probably still meet current needs, but still fall short of what’s possible.

    So I agree with Ken Schwaber’s nuanced description of the PO as a Scrum Team member, but not a Scrum Development Team member. How sharply that dotted line should be drawn will depend on the situation.


  3. Michael James says:

    Here we see it’s not simple.

    As a means of facilitating better communication between Product Owners and the team, we allowed Product Owners to serve as participating members of each team. In some cases, it worked quite well, but in others, POs micromanaged the teams, dictating day-to-day tasks, and impeding honest communication between team members. This has led to teams holding secret meetings to discuss real organizational impediments out of the view of their PO/functional manager. Although these situations appear to be resolving over time, they have crippled the team’s ability to self-organize. When we built the cross-functional Scrums, we disallowed this practice.


  4. Otto says:

    This was an interesting article. I just noticed the difference of the Scrum Team and the Scrum Development Team as Ken Schwaber defines it in “The Enterprise and Scrum”. This first question that came to my mind was “which one of these definitions does the recommended size of 7±2 apply to?”. This question got me googling, but I havent found the answer yet.


  5. Michael James says:

    Otto, most of us are dodging that question. From what I’ve seen, without unusually high bandwidth (like working in one team room), a smaller team will have fewer communication problems in general. So consider splitting the team before it gets to 9 anyway.


  6. Dan Rawsthorne says:

    Otto, according to Ken, the 7±2 applies to the Dev Team – those that are actually doing work producing product. Personally, I don’t like the distinction between Scrum Team and Dev Team, for one primary reason: the SM and PO may be members of the Dev Team, or they may not – it’s optional. This determining if they actually do development or not seems to me like self-organization and self-management. So, I prefer to think of one big self-organizing, self-managing Scrum Team – and the SM and PO can either do development or not… and the 7±2 applies to the total number of Scrum Team members.

    I also note that Ken uses the term “pigs” to refer to the Development Team most of the time, but also explicitly states that the SM and PO are “pigs.” This means that they are supposed to be at the daily meeting, they can speak up, and so on. So, it’s confusing… and I think that making a distinction between those that produce and those that don’t is even more confusing.

    Just sayin’ Dan 😉

    Dan Rawsthorne, PhD, CST
    Transformation Coach

Leave a Reply

Your email address will not be published. Required fields are marked *