Business people and developers must work together daily throughout the project.
—Agile Manifesto
The Product Owner (PO) is the member of the Agile Team who is responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities, while simultaneously maintaining the conceptual and technical integrity of the Features or components for the team. The PO has a significant role in quality control and is the only team member empowered to accept stories as done. For most enterprises moving to Agile, this is a new and critical role, typically translating into a full-time job, requiring one PO to support each Agile team (or, at most, two teams).
The PO role has significant relationships and responsibilities outside the local team. For example, the PO works with Product Management, the role that is responsible for the Program Backlog, to prepare for the Program Increment (PI) Planning meeting.
The PO is the member of the Agile team who serves as the Customer proxy. This person is responsible for working with Product Management and other stakeholders—including other POs—to define and prioritize stories in the team backlog. This activity ensures that the Solution effectively addresses program priorities (features and Enablers) while maintaining technical integrity. Ideally, the PO is collocated with the rest of the team members and typically shares the same management, incentives, and culture. In addition, the PO attends most relevant Product Management meetings about planning and Program Backlog/Vision refinement.
The PO fulfills the following duties.
As a member of the extended Product Management team, the PO is heavily involved in program backlog refinement and preparations for PI planning, and also plays a significant role in the planning event itself. Before the planning event, the PO updates the team backlog and typically reviews and contributes to the program’s Vision, Roadmap, and content presentations.
During the event, the PO is involved with story definition, providing the clarifications necessary to assist the team members with their story estimates and sequencing. The PO also drafts the team’s specific objectives for the upcoming PI.
Maintaining the team backlog – With input from the System Architect/Engineering role and other stakeholders, the PO has the primary responsibility for building, editing, and maintaining the team backlog. Consisting mostly of user stories, it also includes defects and enablers. Backlog items are prioritized based on user value, time, and other team dependencies determined in the PI planning meeting and refined during the PI.
Iteration planning – The PO reviews and reprioritizes the backlog as part of the prep work for Iteration Planning, including coordination of dependencies with other POs. During the iteration planning meeting, the PO is the primary source of story details and priorities and is responsible for accepting the final iteration plan.
Just-in-time story elaboration – Most backlog items are elaborated into user stories for implementation. This may happen before the iteration, during iteration planning, or during the iteration. While any team member can write stories and acceptance criteria, the PO has the primary responsibility for maintaining the flow. It’s usually a good idea to have approximately two iterations’ worth of stories ready in the team backlog at all times. More would create a queue, while fewer might inhibit flow.
Supporting Acceptance Test–Driven Development (ATDD) – POs participate in the development of story acceptance criteria, draft them when feasible, and provide examples in support of ATDD specification by example (see the Test-First chapter).
Accepting stories – The PO is the only team member who can accept stories as done. This step requires validation that the story meets acceptance criteria, has the appropriate, persistent acceptance tests, and otherwise complies with its Definition of Done (DoD). In so doing, the PO also assures a level of quality, focusing primarily on fitness for use.
Understand enabler work – Although POs are not expected to drive technological decisions, they are supposed to understand the scope of the upcoming enabler work and to collaborate with the System and Solution Architect/Engineering team to assist with decision-making and sequencing of the critical technological infrastructures that will host the new business functionality. This can often be best accomplished by establishing a capacity allocation, as described in the discussion of the team backlog.
Participate in team demos and retrospectives – As the person responsible for requirements, the PO has an essential role in the team demos, reviewing and accepting stories. The PO also participates in the Iteration Retrospective, where the teams gather to improve their processes and are active in the Agile Release Train’s (ART’s) Inspect and Adapt (I&A) workshop.
Iterations and Agile teams serve a larger purpose: They provide for the frequent, reliable, and continuous release of value-added solutions. During each PI, the PO coordinates dependencies with other POs. This often occurs in weekly PO sync meetings (see the PI chapter for more information).
The PO also has an instrumental role in producing the System Demo for program and Value Stream stakeholders.
Teams address their larger impediments in the I&A workshop. In that setting, the PO works across teams to define and implement improvement stories that will increase the velocity and quality of the program.
The PI system demo is part of the I&A workshop. The PO has an instrumental role in producing the PI system demo for program stakeholders.
To ensure that they will be able to show the most critical aspects of the solution to the stakeholders, POs also participate in the preparation of the PI system demo.
At scale, a single person cannot handle the entire product and market strategy while also being dedicated to an Agile team. Since Product Management and the PO share the content authority for the program, it’s important to have a clear delineation of roles and responsibilities, as illustrated in Figure 1.
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, POs, and Agile teams must be roughly in balance to steer the ART. Otherwise, the whole system will spend much of its time waiting for definition, clarification, and acceptance. To maximize the chance of success, SAFe recommends a fan-out model, as illustrated in Figure 2.
Each Product Manager can usually support up to four POs, each of whom can be responsible for the backlog of 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.
[2] Larman, Craig, and Bas Vodde. Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.
