Product Owner Role

The Product Owner (PO) is a member of the team responsible for defining features and prioritizing the Backlog to streamline the execution of priorities while 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 features as done.

The PO acts as the single point of contact for the development team, and as the solution expert for the business.

Responsibilities

Planning

• The PO is heavily involved in Backlog refinement and preparation for the planning session and also plays a significant role in the planning event itself. Before the planning event, the PO updates the team Backlog.

• During the planning event, the PO is involved with feature definition, providing the clarifications necessary to assist the team with their feature estimates and sequencing.

Iteration execution

• Maintaining the Backlog. With input from Lead Developer and other stakeholders, the PO has the primary responsibility for building, editing, and maintaining the team backlog. Consisting mostly of user features, it also includes defects and enabler works. Backlog items are prioritized based on user value, time, and other team dependencies determined in the planning meeting.

• Participating in iteration planning. The PO reprioritizes the Backlog as part of the preparation work for Iteration Planning meeting. During the iteration planning meeting, the PO is the primary source for feature detail and priorities and has the responsibility of accepting the final iteration plan.

• Elaborating features. Most backlog items are elaborated into user features for implementation. This may happen before the iteration, during iteration planning, or during the iteration. While any team member can write features and acceptance criteria, the PO has the primary responsibility for maintaining the flow. It’s usually good to have approximately two iterations' worth of features ready in the team backlog at all times. More would create a queue, while less might inhibit flow.

• Supporting Acceptance Test–Driven Development (ATDD). The PO participates in the development of acceptance criteria, draft them when feasible, and provide examples in support of ATDD specification by example.

• Accepting features. The PO is the only team member who can accept features as done. This includes validation that the feature meets acceptance criteria and has the appropriate, persistent acceptance tests, and that it otherwise complies its Definition of Done (DoD). In so doing, the PO also assures a level of quality, focusing primarily on fitness for use.

• Understanding enabler work. While the PO are not expected to drive technological decisions, they are supposed to understand the scope of the upcoming enabler work and to collaborate with the technical team(s) to assist with decision-making and sequencing of the critical technological infrastructures that will host the new business functionality.

• Participating in team demo and retrospective. As the person responsible for requirements, the PO has an essential role in the team demo, reviewing and accepting features. They also participate in the Iteration Retrospective, where the teams gather to improve their processes.

Business support

• Training the users. The PO is responsible for providing training to the application users when needed.

• Supporting users. The PO acts as the first level of support for application users, as it may be a lack of training or a known problem that has a work around. The PO reports a defect by adding it to the Backlog.

Source: Product Owner