The Product Owner accountability is vital in Scrum. At the same time, it is widely misunderstood. What is the problem, you may ask? They can be catastrophic. Organizations may draw the wrong conclusion about what Product Owners should do, what Scrum teams should do and what Scrum is for. With that, they invalidate the Scrum Team, what they can accomplish and in the end the organization.
I feel compelled to write this article. I believe I am in the position to do so. I know a thing or two about Scrum. I am the co-founder of Serious Scrum, together with Sjoerd Nijland. With like-minded people, we were able to grow this Serious Scrum to be the largest Scrum community in the world. I am PSM III, published hundreds of articles about Scrum, engaged with Scrum thought leaders of the world and I was part of Scrum teams for years.
Too many people have written articles and books, and given presentations presenting fantasy as facts out of ignorance. This is why inform you about my background. Am I a Scrum defender? I leave this up to you. I like Scrum, but I don’t think it is perfect. But most importantly: I wish to right the wrongs about Scrum to counterweigh the nonsense.
In this rectification, the latest Scrum Guide will be my reference.
1. The Product Owner is assigned to a team
This is a tricky one to explain. But I must start with this one to rectify other more egregious misconceptions. Yes, the Product Owner is a member of the Scrum Team. No, the Product Owner isn’t a team backlog owner.
As the accountability’s title explains: they are “accountable for maximizing the value of the product resulting from the work of the Scrum Team.” - Scrum Guide 2020. The Product Owner’s focus is the product.
Sometimes more Scrum Teams need to work on the same product: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product.” - Scrum Guide 2020. Whenever that happens, there is ONE Product Owner who is a part of multiple teams.
2. The Product Owner is responsible for the product delivery
No! The Product Owner is accountable for maximizing the value of the product. They do this through the results of the Scrum Team. Granted, the Scrum Team creates value through delivering items ideally every Sprint. However, it is important to understand WHY the Scream Team delivers this frequently.
Scrum is a framework to create valuable products in a complex environment. “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” - Scrum Guide 2020
The Scrum Team doesn’t work on a conveyor belt, churning out features. They build upon the product frequently to receive feedback on what they created. This feedback (together with other important developments) is helping the Product Owner to reorder the Product Backlog. The new insights enable them to maximize the value of their product.
This is why the Product Owner is not responsible for product delivery, but rather for product discovery.
The Product Owner’s sole job is to do backlog management
In this article, I only look at the Scrum Guide. But even then, this statement is untrue.
The Product Owner creates and communicates a Product Goal. This Product Goal is the desired future state of the product.
The Product Owner proposes a Sprint Goal to take a step towards the Product Goal.
The Product Owner engages with stakeholders (like users, and internal stakeholders) to inform themselves about how to maximize the value of their product.
The Product Owner is no Product Manager
This depends. The Product Owner is a Scrum accountability. Anyone can have this accountability. They could be the CEO, a Developer, a customer, a sales representative and also a Product Manager. Scrum is intentionally flexible because every organization is different.
Scrum doesn’t position the Product Owner as a job function. However, looking at what the Scrum Guide says, there’s plenty of Product Management:
The Product Owner makes the product decisions and everyone respects these decisions. “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” - Scrum Guide 2020
The Product Owner is accountable for product value maximization.
The Product Owner engages with stakeholders.
You may now say “But a Product Manager does more!” And you are right. A Product Manager does far more than what the Scrum Guide describes for a Product Owner. However, this is not Scrum related. Therefore this doesn’t need explaining in the Scrum Guide. A developer does more too. But you won’t find explanations of how to code in the Scrum Guide. The same is true for a designer, a UX expert, a finance expert, whatever role is needed to create the product.
For example, the Product Manager must develop a Product Strategy and Vision. These are essentially ways to start building the Product Backlog. The Product Backlog Items describing the Product Strategy may be big, broadly described and not specific enough to work on. But that is fine. They will be refined later. The Product Vision can be the Product Goal.
The Product Manager may need to do Market and User Research. They can do this using Scrum. Remember, Scrum is aimed at complex environments where you gradually learn more by taking small steps and learning from that.
Scrum helps you work with a learning loop by creating one or more product increments every Sprint. How you do this, including if and how the Product Owner does the Product Management work, is up to the organization, the team and its individuals.
5. The Product Owner owns the Sprint Backlog and determines what the team does
This is untrue. Firstly, the entire Scrum Team determines the Sprint Goal which defines what they wish to achieve in the Sprint. Then the Developers select the items from the Product Backlog as ordered by the Product Owner. Lastly, the Developers create a plan for the Sprint.
The Developers own the Sprint Backlog, which has the Sprint Goal, selected items and the plan. Only they can add, change or remove items from the Sprint Backlog. This is because the Developers know how to achieve the Sprint Goal and no one else. That said, they are limited in what they can change, as they can’t endanger the Sprint Goal. Also, Developers should collaborate with the Product Owner whenever they wish to change the Sprint Backlog.
End Note
I sincerely hope this article helps people to have a better understanding of the Product Owner accountability. The information I brought here is right from the source: the Scrum Guide.
Sadly, other approaches like SAFe have hijacked the Product Owner accountability and twisted it to be something else. I am baffled that they are still called Product Owners.
What’s worse: this false idea of a Product Owner is taking over the narrative. This is to the detriment of the Product Owners who work with Scrum Teams to create value and end up misunderstood and undervalued.
Again a very good article that hits the nail on its head. We have to be careful however, if you're right that some people are confounding the role of PO in Scrum and the one in SAFe, we shouldn't dismiss SAFe simply because it is not Scrum. It's unfortunate that our language favors such ambiguity over more distinctive appellations, but we aren't Ents to discuss about it all day. This convenience comes with the responsibility of trying to avoid creating relation where none exist.
On my part, I think SAFe isn't to be blamed for the PO confusion, but put the blame to the poor implementation of Scrum many have been subjected of. Could be just anecdotal, but I have seen tons of misunderstood PO roles in Scrum (as well as SM and even Devs!) but my contact with people having actual experience with SAFe have been minimal (and yet, still suffer a similar misunderstanding that Scrum has). At least, articles like your are a step in the right direction.
I still consider that our biggest problem in this complex industry is still our attachment to a silver bullet solution, a magic pill making everything clear, simple, stable and certain. It's what block us to embrace the growth mindset required to deal with our complex and messy reality. Thanks for giving us some light on that subject.
You can easily tell that people do not understand Scrum when they equal the Product Owner with Product Backlog management. What keeps me wondering is that 1. people do nor like to learn, even by doing the bare minimum, 2. people hold on to use the terminology and 3. people see value in making uninformed negative judgements. If Scrum is not your thing, even if you do not even know it, fine! Then do not use it.