The Product Owner is a key role in Scrum, but many organisations struggle to effectively apply it. As the name suggests, a product owner should own the product; he is responsible for ensuring that the product creates value for its customers and users as well as the company providing it.
The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team.
The PO, according to this article, knows how to act on different levels. The most common way to define these levels is strategic, tactical and operational. A Product Owner should know how to explain the product strategy at board level, create support at middle management and motivate the development team with their daily challenges.
Each agile team, or in the case of large programs an agile sub-team, has a single product owner to go to for information and prioritization of their work and they do so right away. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst/project manager.
Part of the product owner’s responsibilities is to have a vision of what he or she wishes to build and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.
It is important to note that although a PO says what features need to be implemented first, he never interferes with the team planning. The Scrum team selects the features to implement for each sprint, according to their velocity and feature priority; the Product Owner cannot push more features in a sprint just because he wants them faster. Team members know best what they are capable of, and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.
As a reward for the Scrum teams’ commitment to completing the selected user stories from the top of the product backlog, the PO ensures that no new requirements are introduced during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint, it remains focused on the goal of that sprint or if the entire team (business’ team and technical’ team) decide to do so.
Communication is a large part of the product owner’s responsibilities. The product owner role requires working closely with key stakeholders throughout the organization and beyond, so he or she must be able to communicate different messages to different people about the project.
The product owner can’t possibly know all the details known by the true range of stakeholders at all points in time and as a result he or she will need to bring stakeholder experts to the team to share their expertise with the team at appropriate times. The implication is that the PO isn’t always the direct source of requirements.
The PO is the connection between business requirements and technical requirements. Still, in different teams we can find that PO is business analysts or technical team leaders – this is not necessarily a bad thing, but it depends on the way the PO is doing the separation of responsibilities. These responsibilities are the same and don’t depend on agile software development.