Myth: The Product Owner Exclusively Maintains the Product Backlog

What is a Product Backlog?

Product backlog consists of desired product functionalities that provide a centralized and shared understanding of what to build and the order in which to build it. Consider it as a medium of creating transparency and roadmap across the board.

The Product Backlog contains Product Backlog Items or PBIs which usually are features, items of functionality that will have tangible value to the user and customer. The PBIs are often written as user stories, sometimes use cases or free form text. Other PBIs include defects, technical improvements and any other work the product owner deems valuable. The flow is explained in the below diagram.

Who is responsible for the Product Backlog?

As per the scrum guide, a product owner is responsible for the product backlog. Developers look at the product owner to articulate and detail all the requirements in the product backlog items. Further, he also needs to order the requirements based on their respective business value. In this post, I will try to explain why this is a myth.

Ordering of Product Backlog

Many teams are still not clear or get confused when it comes to differentiating between the business value (Priority) and the logical sequencing (order) of the backlog. It is not necessary that a product backlog item (PBI) with the highest business value gets the top order in the development sequence. 

To explain this transition, I often use the below example by James Coplien to bust the myth of prioritization. 

“With the heavy downpour that occurs every afternoon, it is important to get a roof over your head as soon as possible. The Product Backlog for your house will contain all the things that make up a house, like doors, windows, walls and obviously a roof. If you were to order this Product Backlog solely by priority, the roof would certainly end up on top. It needs to keep you dry. But this ordering does not reflect how you’re actually going to build your house. You can’t build a stable roof without walls, and you can’t build walls without a foundation. So instead of starting with the roof, you’ll probably start with the foundation of your house. The order of the Product Backlog will be influenced by such things as dependencies, efficient use of materials, availability of third parties and building codes. Only ordering by priority is not going to get you a stable, robust and safe house to get you through those wet and rainy afternoons.”

From the above, you would agree that the development order does not have 1-to-1 mapping with the business priorities. As priorities drive pairwise comparisons, it was removed from Scrum after a long-held understanding by many leaders in the Scrum community.

Need of Collaborative Efforts in the Product Backlog Management

A product owner works with the business and development teams to create the product backlog that is ever evolving throughout the life of the product. Being responsible doesn’t mean that it is solely the duty of a product owner to do all these tasks by themselves. You might disagree with me but I have hardly met a product owner who is able to do all these without a very close team collaboration. Imagine, a new product owner joining in the middle of development who has no background of the product; would you expect him to order the backlog? Once the Sprint scope is agreed, the scrum team can order it. However, as a business point of contact, the product owner remains responsible for the product backlog.

In development, the in-depth knowledge of the ecosystem, dependencies and business rules might be challenging for a product owner alone to champion. These are often determined, created and ordered in very close collaboration or by the development team and anyone in the scrum team can create a new PBI and change the order in agreement with the product owner. Agile mature teams follow this through continuous refinement throughout the development cycle. This is reviewed in the sprint planning and agreed for development. 

On the other side, geographically distributed teams add challenge with product owners operating from delivery locations where this role gets diluted being closer to the delivery team than business. Moreover, the role of a pure product owner is often missing in the engagements or more often coupled with the role of a business analyst.

The Product Owner remains responsible for the product backlog but that does not mean that it is their sole responsibility. Trust is the most important pillar in Agile and for that same reason, anyone in the team can create user stories, tasks, requirements to deliver against a product requirement from the backlog. Teams not following this practice are often seen blaming the product owners for any miss or disconnect in the product flow.

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 Development Team in each Sprint, it makes sense for the Product Owner to actively work with the Development Team to write items, refine, and order them. In complex work, it’s all about the effective collaboration between professionals.

For further reading, refer to the below post from scrum.org that also explains this to clear the myth that only a product owner can maintain the product backlog.

https://www.scrum.org/resources/blog/myth-product-backlog-maintained-exclusively-product-owner