Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve complex problems with an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths. In this series of posts we — your ‘Mythbusters’ Christiaan Verwijs & Barry Overeem — will address common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here.
Myth: The Product Backlog is maintained by the Product Owner
Is your Product Owner the only person who can make changes to the Product Backlog? Are your Developers asking your Product Owner to write and order all the items on the Product Backlog? Is the Product Owner the only person with write-access to a Product Backlog in a digital tool like Jira?
Taken together, the theme here is that the Product Owner is the person who is responsible for maintaining the Product Backlog. In this post, we’ll show why this is a myth.
What does the Scrum Guide say?
The Scrum Guide says the following about the Product Backlog and who is responsible for it:
“The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.”
You can read this line as reinforcing the idea the Product Owner should also do all these things. So, the Product Owner should write all the items on the Product Backlog. The Product Owner should order them. And the Product Owner should make the Product Backlog available to both the Scrum Team and stakeholders.
But the Scrum Guide then continues to describe that the Product Backlog is dynamic and constantly evolves in “an ongoing process in which the Product Owner and the Developers collaborate on the details of Product Backlog items”.
The keyword here is “responsible”. Ask yourself this; can a Product Owner maximize the value of work done by the Scrum Team if they are not involved in what goes on the Product Backlog and in what order?
Common Causes
There are many different reasons for this myth to come into existence. One common cause is when Product Owners double as (business) analysts or come into the role from this background. From this perspective, it might seem sensible for them to take care of all of the ‘requirements analysis’ that is required to populate a Product Backlog. Often, Developers encourage this so they can focus on what they assume is their most important task: write code. But this is not how the roles are intended.
Another common cause is the interpretation of ‘Scrum as a methodology’. Organizations eagerly turn Scrum roles into formal job descriptions. When Scrum is completely new to them, they try to understand new roles from traditional perspectives: Product Owners are responsible for requirements (analysts), Scrum Masters are responsible for the team (team leads or team managers) and Developers are responsible for writing code (coders). But by doing so, they fail to understand the purpose behind the Scrum Framework. They don’t understand why we are doing all of this in the first place.
So let’s return to the roots so we can understand.
Back to the essentials of Scrum
To better understand why this is a myth, we have to return to the essentials. The Scrum Framework exists to decrease the risks inherent to product development and other complex work. Far more often than not, product development is complex work where more is unknown than known. Because of this, we need close collaboration between professionals and the involvement of many minds to make sense of what is happening and identify the next steps. In complex work, hierarchy only gets in the way of creativity, motivation, and the intelligence of teams.
“In complex work, hierarchy only gets in the way of the creativity, motivation, and intelligence of teams.”
From this perspective, it makes no sense to treat the Product Owner as the only person who can create items for the Product Backlog and order them. By treating the Product Owner like this, we are introducing hierarchical thinking into a framework that is fundamentally antithetical to it.
And this goes both ways. Product Owners should work closely with the Developers to create items for the Product Backlog and order them to maximize the value of work done by them. Developers, on the other hand, should proactively seek this out as well by offering suggestions for both items on the Product Backlog as their ordering. They should actively work with Product Owners to refine and clarify items, making sure they are understood both by the Scrum Team as by stakeholders. Scrum Masters, in turn, should help both the Product Owner and the Developers understand that this is the most effective way to collaborate in complex work.
In fact, it is perfectly fine for Developers to be even more proactive and put items on the Product Backlog or re-order them if the Product Owner believes that this is the best way to maximize the value of their work. But ultimately, the Product Owner remains responsible for what goes on the Product Backlog and in what order - they have the final say. The Product Owner is the person you should go to when this isn’t the case.
“It is perfectly fine for Developers to be even more proactive and put items on the Product Backlog or re-order them if the Product Owner feels that this maximizes the value of the work they do.”
A couple of Scrum Teams (more in the back) working together to formulate product strategies and clean up their Product Backlogs together.
Tips
- Organize ‘Product Discovery Workshops’ where you invite everyone on the Scrum Team to collaborate on the creation and ordering of items on the Product Backlog. But keep in mind that these kinds of workshops work best when they are not required and people can ‘opt-in’ with their participation;
- When using digital tools like JIRA, reduce restrictions to who can change the Product Backlog and include the Developers. If only the Product Owner can do this, you are only reinforcing this myth. Instead, make work agreements about what kind of changes the Developers can make on their own and what level of communication with the Product Owner is desired;
- As a Scrum Master, make sure to emphasize that the Scrum Framework offers a sensible approach for reducing the risk of work. Don’t explain the Scrum Framework, its roles, its rules, and its events as if you’re quoting the bible. Myths like these start popping up when people only understand the rules, not the purpose behind them;
- If you’re a fan of Liberating Structures — like we are — you have access to an awesome repository of microstructures to trigger exactly the kind of collaboration we’re looking for. You can use Ecocycle Planning or Min Specs with the Scrum Team to clean up and order the Product Backlog. Or use structures like 1–2–4-ALL, TRIZ, and 25/10 Crowd Sourcing to generate ideas. Or invite the Scrum Team to work together to craft product strategies with Critical Uncertainties;
A bit closer to home, here Barry Overeem is acting as Product Owner for our website & online marketing. The Product Backlog is fully transparent and was populated throughout development mostly by the Developers, while the Product Owner kept the focus on what was important in terms of value.
Closing
This myth strongly underscores that Scrum is far more than a bunch of roles, rules, and events. When we run into myths like this, it helps to go back to what it is we are trying to achieve with Scrum and interpret it from that perspective.
The Product Owner ensures that there is a Product Backlog, that it is ordered, and that it is made available to both the Scrum Team and stakeholders. This is the person you go to when this is not the case. But this doesn’t mean that the Product Owner is the only person in the Scrum Team who does this. In order to maximize the work done by the Developers in each Sprint, it makes sense for the Product Owner to actively work with the Developers to write items, refine, and order them. In complex work, it’s all about the effective collaboration between professionals.
