The blog post agile product ownership in a nutshell by Henrik Kniberg is a high level summary of agile software development as viewed by the product owner. Henrik calls it “a 1 day product ownership course compressed into a 15 minute animated presentation”. He suggests to watch the video about agile product ownership; a transcript is also available. To give an impression of what the video covers, below are some citations.
In scrum, stakeholder needs which are expressed in user stories are put in a queue. This queue is called a product backlog, and the product owner is responsible for it:
The product owner decides what goes in, and what goes out. The product owner also decides the sequencing – what do we build now, what do we build later? This is a hard job, and needs to be done in collaboration with the team and stakeholders.
The product owner and the team collaborate to manage the product backlog:
All this stuff I’ve been talking about – estimating the value and size of stories, prioritizing, splitting – all that is usually called “backlog grooming”. Pat runs a backlog grooming workshop every wednesday from 11:00 – 12:00. The whole team is usually there, and sometimes a few stakeholders as well. The agenda varies, sometimes the focus is on estimation, sometimes on splitting stories, and sometimes on writing acceptance criteria for a story.
Each scrum role has it own focus for developing software products:
There is a healthy tension here between the Scrum roles. POs tend to focus on building the right thing. Teams tend to focus on building the thing right. And Scrum masters, or agile coaches, tend to focus on shortening the feedback loop.
The product owner and the team collaborate to balance quality and progress:
If the team is accumulating technical debt – if they’re not writing tests, and not continuously improving the architecture – then the they will get slower and slower over time, and the story burnup curve will flatten out. That makes forecasting almost impossible. So the team is responsible for maintaining a sustainable pace, and [the product owner] avoids pressuring them into taking shortcuts.
Larger projects with multiple teams will have more then one product owner. Collaboration between the product owners is necessary:
In a multi team scenario, however, the POs have an important additional responsibility – to talk to each other! We should organize the teams and backlogs to minimize dependencies. But there will always be SOME dependencies. So there needs to be some kind of sync between the product owners so that we build things in a sensible order, and avoid sub optimization.
Mountain Goat Software describes the product owner role in learning scrum – the product owner. The product owner has a vision of what they wish to build and conveys that to the scrum team. The team and the product owner collaboratively decide how much will be developed in a sprint:
The product owner does not get to say, "We have four sprints left, therefore you must do one-fourth of the product backlog this sprint." The product owner's job is to motivate the team with a clear, elevating goal. 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.
Also the product owner and the team have agreed on how they will manage requirements changes:
In return for the scrum team's commitment to completing the selected user stories from the top of the product backlog, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint.
Faisal Mahmood discusses in the blog post should the product owner attend daily scrum, product owner and team engagement how product owners collaborate with agile team in meetings. Faisal explains why the product owner should attend the sprint planning, sprint review and retrospective meetings:
[The Product Owner] describes the Product Backlog Items (user stories or requirements in other formats) to the team. She works together with the team to ensure that she shares a common understanding of the scope of the Product Backlog Items (user stories etc). (…) Product Owner participation in a Sprint Planning meeting is a must, otherwise the team may pick items with low value, or no value at all. This leads to waste, confusion and wasted opportunities.
Sprint Review provides the last opportunity to the Product Owner to accept or reject work. The Scrum team (the Product Owner, the team and the Scrum Master) and stakeholders discuss changes in the product direction, market or competitive landscape during the Sprint Review. This discussion leads to an updated Product Backlog. Thus the Product Owner participation in a Sprint Review meeting is crucial.
It is very difficult, if not impossible, for the Scrum Team to improve the way it plans the Sprints, manages and updates the Product Backlog, grooms the Product Backlog, the way it engages with the Product Owner and stakeholders and the way it conducts Sprint Reviews if the Product Owner is not present in the Retrospective meetings.
The scaled agile framework, created by Dean Leffingwell, supports applying lean and agile practices at enterprise scale. It describes the product owner role:
The Product Owner is the member of the team responsible for both defining and prioritizing the Team Backlog (Product Backlog in generic Scrum). In addition, the product owner has a significant role in quality, and is the only team member empowered to “accept” new stories into the system baseline. For most enterprises converting to agile, this is a new, and critical role, which typically translates into a full time job (typically one PO per one to two agile teams).
According to Dean, enterprises that develop software with agile methods will have to balance multiple product managers, product owners and 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, or the whole system will spend much of its time waiting for definition, clarification and acceptance.
Marc Löffler describes the benefits of product owner teams in his blog post 5 reasons why a product owner team might be a good idea. One of his reasons for a product owner team is the availability of a product owner for an agile development team:
Ever heard about ScrumMasters taking over the role of the PO, when he is not available? Bad idea! But it does happen and not only once. This is another good reason for a PO team. Even if one or two members of the team are not available (ill, on vacation), the team is still able to work.
Another reason Marc mentions is that team working of product owners can improve the quality of the backlog:
I know that there are no rules that the PO should be the only person to create new items in a backlog, but many teams think so. A PO team forces them to work together. Of course they still have to work tightly with the development team, do backlog grooming sessions or even ask a developer to help to maintain the backlog. A PO team will help to foster the collaboration in a team.