Is the Product Owner a Team Member?

Product Owner Team Member
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.


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?


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.


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.


  • 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.

A Swarming State of Mind

In a previous blog post, I discussed how sprint planning can help put the team in position to effectively swarm on tasks.  If building software is like playing golf, sprint planning is akin to assessing playing conditions, determining yardage, selecting a club, and setting up to hit the ball.  While the golfer has a few minutes to do all of these things, the act of actually swinging the club and hitting the ball allows little time for conscious thought or strategic decision-making. The player often acts based on habit and what feels right.


The same is true for task execution during a sprint. With the challenge and pressure of the sprint timebox, team members who are new to agile often revert to pre-agile habits. Signs include:

– Team members or (gasp) the ScrumMaster pre-assigning tasks to specific team members at the beginning of the sprint

– Team members only working on tasks that fit squarely within their skillset

– Each developer taking a user story to work on by themselves

Pre-assigning tasks:

No ScrumMaster worth their salt would assign tasks to team members as it is would be a violation of them principle of team self-organization.  Oh – not to mention totally disempowering the team as well.  Team members, on the other hand, may be tempted to pre-assign tasks. Having completed a sprint plan, they may proceed to divide up the sprint work and then head off in their separate directions to take care of their assignments.  This creates a couple of problems.

  • Having too many user stories in progress (think WIP) at the same time. This creates bandwidth issues for the customer, who is charged with participating in conversations about each story, writing acceptance tests for each story, and testing each story. Worst case, it can put the team in the position of having 80% of 100% of the stories done at the end of the sprint, which delivers zero value to the customer.
  • Promoting individual team member ownership of user stories rather than whole-team ownership.  This ownership can possibly impact others’ commitment to jump in to help out on the story, but more importantly it makes it harder for others to get up to speed to understand the story and the technical implementation if they were not involved in the conversations with the customers or any of the coding.

A pattern that minimizes work in process and maximizes team ownership is to not pre-assign tasks.  As team members finish a task, they look for the next available task to work on, even if it is for a story that someone else has started.

Working on tasks only within skillset:

We all know by now that Scrum prescribes three roles: Product Owner, Scrum Master, and Team Member. Putting aside discussions about whether the Product Owner or Scrum Master is a member of the team, the key point is that there is one Team Member role.  There are not separate roles for Web Developer, Data Base Developer, Data Architect, DBA, QA, etc. Properly constituted agile teams consist of specialized generalists with t-shaped skills. But skills are only part of the equation.  Desire for team success is paramount.  This means that a DBA is willing to help with QA testing in order to help meet the sprint commitment.

Developers who prefer to work on stories by themselves:

Sometimes Scrum Masters or functional managers have to make a hard assessment of whether team members prefer to work mostly by themselves. Not to be confused with introverts, some people gravitate toward coding because it allows them to delve deeply into the intellectual challenge of piecing together great code.  Before agile, so many buffers existed between developers and customers that loners could be valuable contributors to project teams as long as the team lead or systems analyst could be relay information to/from the customer and those developers.  These same types of developers struggle in the highly-collaborative world of agile teams.


  • Resist the temptation to pre-assign tasks at the start of a sprint. Strive to minimize WIP and maximize whole-team ownership of stories.
  • A culture that values team success rather than individual achievement is key.
  • Not all individuals are a good fit for agile teams.