The Product Owner accountabilities, as defined by the Scrum Guide 2020, are:
– Developing and explicitly communicating the Product Goal;
– Creating and clearly communicating Product Backlog items;
– Ordering Product Backlog items; and,
– Ensuring that the Product Backlog is transparent, visible and understood.

Empiricism in Scrum is built on transparency, inspection and adaptation. Reviewing a «Done» increment enhances transparency. Inviting all relevant stakeholders improve inspection and adaptation. Forcing Developers to deliver all the Sprint Backlog may reduce their transparency during Sprint Review. Having a detailed demo of the features may slow down the event and the feature validation it is not the goal of the event.

Although true cross-functional Scrum Teams are preferred in Scrum, because they can deliver complete Product Backlog Items (PBI) without external dependencies, that organizational structure is not mandatory in Scrum. Scrum Teams can eventually collaborate with external stakeholders or teams to complete PBI.

All Developers are accountable as a whole for the quality of the Increment, regardless one of them is leading the quality activities.

A product with low CV needs to be assessed, either to invest in it to improve it, or kill it because there is no possible improvement. Since UV is low, there is little to improve, so it may be in the decline phase.

The Product Backlog is updated whenever it makes sense during the Sprint time, mainly by the Product Owner. Changes are triggered by new information or needs appearing, based on the feedback on the Sprint’s increment or other sources.

The definition of «Done» helps the Product Owner to understand the right quality is delivered to the users, specially during inspection happening in Sprint Reviews. The Product Owner does not need to control the Developers if the Scrum Values are in place. Although the level of quality delivered may help to understand the cost of the development, is not the goal of the definition of «Done».

The Product Owner should «Creating and clearly communicating Product Backlog items», but that does not imply creating the acceptance criteria. That can be done by other team members, or even stakeholders external to the team.

The Sprint Review is meant to inspect the increment and adapt the Product Backlog for future Sprints with information from different sources, such as product usage metrics, relevant feedback from the Stakeholders, learnings from the Sprint or market trends. Other events are focused on planning and tracking the Sprints, or improving the team.

Customer satisfaction is a proxy for value created for the user. User productivity is a direct value metric. Velocity and bug density metrics are aligned to the delivery process. Features available describe the product, but not the value created by those.

A Product Owner can maximize value created by the Scrum Team by facilitating communication among the Team and all stakeholders, without becoming a bottleneck in conversations non-relevant for Backlog management. Representing the interests of users and other stakeholders guide Developers in taking value-driven decissions. Transparency around the Increment and definition of «Done» help everybody to inspect and adapt on Sprint Reviews.

Developers can work in the Product Backlog and provide support to the Product Owner. Write and analyze User Stories can also be done by Developers. Estimating items and identifying (technical) dependencies can only be done by Developers. However, ordering the Backlog and defining Releases can only be decided by the Product Owner.

Scrum promotes self-management of the Scrum Teams. A good starting point upon team creation is to allow the team members to coordinate and choose team and responsibilities. Neither the Scrum Master nor the Product Owner are bosses of Developers to order them how to organize.

The Scrum Guide does not prescribe release management practices for the Product Owner. Story Points or Release Burndown may be common practices, but not standard in Scrum. Technical debt may be discussed with Developers and considered for release calculations, but again it’s not a standard practice.