Product Owner

Business people and developers must work together daily throughout the project.

—Agile Manifesto

Product Owner Abstract

The Product Owner (PO) is the member of the team responsible for defining Stories and prioritizing the Team Backlog so as to streamline the execution of program priorities, while maintaining conceptual and technical integrity of the Features or components the team is responsible for. The PO has a significant role in quality and is the only team member empowered to accept stories as done. For most Enterprises converting to Agile, this is a new and critical role, which typically translates into a full-time job, requiring one PO to support each Agile Team (or, at most, two teams).

The role has significant relationships and responsibilities outside the local team, including working with Product Management (who are responsible for the Program Backlog) to prepare for the PI Planning meeting.


The Product Owner (PO) is the member of the Agile Team who serves as the Customer proxy and is responsible for working with Product Management and other stakeholders—including other Product Owners—to define and prioritize Stories in the Team Backlog so that the Solution effectively addresses program priorities (Features/Enablers) while maintaining technical integrity. Ideally, the Product Owner is collocated with the rest of the team, where they typically share management, incentives, and culture. But the Product Owner also attends most relevant Product Management meetings about planning and backlog/Vision refinement.


The SAFe Product Owner fulfills the primary responsibilities outlined below.

Preparation and Participation in PI Planning

  • As a member of the extended Product Management team, the Product Owner is heavily involved in Program Backlog refinement and preparation for PI Planning and also has a significant role in the planning event itself. Prior to the event, the Product Owner updates the team backlog and typically participates in reviewing and contributing to the vision, Roadmap, and content presentations.
  • During the event, the Product Owner is involved with story definition, providing clarifications necessary to assist the team with their story estimates and story sequencing, and drafting the team’s specific objectives for the upcoming Program Increment (PI).

Iteration Execution

  • Backlog Refinement. With input from System Architect/Engineering and other stakeholders, the Product Owner has the primary responsibility for building, pruning, and maintaining the team backlog. The backlog consists mostly of user stories but also includes defects and enablers. Backlog items are prioritized based on user value, time, and other team dependencies that are determined in the PI planning meeting and refined during the PI.
  • Iteration Planning. The Product Owner reviews and reprioritizes the backlog as part of the preparatory work for Iteration planning (see “Plan the Iteration” in ScrumXP), including coordination of content dependencies with other Product Owners. During the iteration planning meeting, the product owner is the main source for story detail and priorities and has the responsibility of accepting the final iteration plan.
  • Just-in-Time Story Elaboration. Most backlog items are elaborated into user stories for implementation. This may happen prior to the iteration, during iteration planning, or during the iteration itself. While any team member can write stories and acceptance criteria, the Product Owner has the primary responsibility for keeping the process flowing. It is usually good to have approximately two iterations’ worth of ready stories in the team backlog at all times. More would create a queue, while less might inhibit flow.
  • Supporting ATDD. POs participate in development of story acceptance criteria, draft them when feasible, and provide examples in support of ATDD (acceptance test-driven development) specification by example. See Test-First.
  • Accepting Stories. The PO is the only team member who can accept stories as done. This includes validation that the story meets acceptance criteria and has the appropriate, persistent acceptance tests, and that it otherwise meets its Definition of Done. In so doing, the PO also fulfills a quality assurance function, focusing primarily on fitness for use.
  • Understand Enabler Work. While Product Owners are not expected to drive technological decisions, they are expected to understand the scope of the upcoming enabler work and to work with System and Solution Architect/Engineering to assist with decision-making and sequencing of the key technological infrastructures that will host the new business functionality. This can often best be accomplished by establishing a capacity allocation, as described in the Program and Value Backlog article.
  • Participate in Team Demo and Retrospective. As an integral member of the team and the one responsible for requirements, the PO has an important role in the Team Demo, reviewing and accepting stories; and in the iteration retrospective (see “Retrospect and Improve” in ScrumXP), where the teams gather to improve their processes. POs are also active participants in the ART’s Inspect and Adapt workshop.

Program Execution

  • Iterations and teams both serve a larger purpose: frequent, reliable, and continuous release of value-added solutions. During the course of each PI, the Product Owner coordinates content dependencies with other Product Owners. This is often accomplished in part by attendance at weekly PO sync meetings. See the Program Increment article for more information.
  • The Product Owner also has an instrumental role in producing the System Demo for program and Value Stream stakeholders.

Inspect and Adapt

  • Teams address their larger impediments in the PI inspect and adapt workshop. There, the Product Owner works across teams to define and implement improvement stories that will increase the velocity and quality of the program.
  • The PI system demo occurs as part of the inspect and adapt workshop. The Product Owner has an instrumental role in producing the PI system demo for program stakeholders.
  • POs also participate in the preparation of the PI system demo to make sure that they will be able to show the most critical aspects of the solution to the stakeholders.

Content Authority

At scale, a single person cannot handle product and market strategy while also being dedicated to an Agile Team. Since Product Management and the Product Owner share the “content authority” for the program, it is important to have a clear delineation of roles and responsibilities, as is illustrated in Figure 1 below.

Figure 1. Release content governance
Figure 1. Release content governance

Fan-out Model of Product Manager, Product Owner, and Agile Teams

Successful development is, in part, a game of numbers in the Enterprise. Without the right number of people in the right roles, bottlenecks will severely limit velocity. Therefore, the number of Product Managers, Product Owners, and Agile Teams must be roughly in balance in order to properly steer the Agile Release Train (ART), or the whole system will spend much of its time waiting for definition, clarification, and acceptance. The Framework recommends a fan-out, as illustrated in Figure 2.

Figure 2. Fan-out Model for PM/PO
Figure 2. Fan-out model for PM/PO

Each Product Manager can usually support up to four Product Owners, each of whom can be responsible for the backlog for one or two Agile Teams.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 11.

[2] Larman, Craig, and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010, chapter 3.

Last update: 6 April 2016