Scrum prescribes three roles:  Product Owner, Scrum Master, and Team Members.  The Team Members consist of developers, DBAs, QA people, and others who do the coding, testing, and other work to bring software to life.  Team Members rely on the Product Owner to provide information about requirements as well as to create and execute acceptance tests. If the Product Owner has such a key role in getting stories to “done”, then they become defacto members of the team.

Beware of teams that do not invite Product Owners to retrospectives, or where their participation in Sprint Planning is limited to a Q&A session at the start of planning after which they are asked to leave. These fly is the face of working collaboratively and building trust.

The key to making the Product Owner part of the team is for the Product Owner to recognize that while they will participate in several team actvities, they are only a team member up to a certain point.  There are lines that they should not cross.

Estimates

When the team is sizing stories or estimating tasks, the Product Owner’s role is to provide information about requirements but not to estimate the work.  It is very easy for a Product Owner who is trying to squeeze more into an iteration to pressure the developers into lowering estimates.  The Product Owner needs to recognize that if they are not doing most of the work on a user story by themselves, they should keep quiet about estimates.  The only exception to this is when they feel that something has been grossly overestimated because the requirements were misunderstood.  Otherwise, will the team really be committed when the developers know in their hearts that the estimates are unrealistic? Does this set stage for developing at an unsustainable pace?

Self-Organization

When an iteration starts and the team is determining how to approach the work, the Product Owner (just like the Scrum Master) must refrain from assigning tasks or dictating the approach. A self-organized team is an efficient and committed team. The Product Owner needs to let the team find its way for true growth and improvement to occur.

Retrospectives

When the Product Owner attends the retrospective, they absolutely must not assume an authority role.  It is not their place to lecture the developers, DBAs, or QA people about what they did wrong in the sprint. In all likelihood the Scrum Master has observed the same issues and will help the team through a self-discovery process that sets the stage for effective adaptation.

Reflections:

• The Product Owner is a member of the team.
• The Product Owner must understand that there are certain team activities (such as estimating) in which they cannot directly participate.
• The Product Owner cannot exert authority over the team when acting as a team member.