Scrum is a framework used to deliver value in complex environments. The Product Owner’s purpose is to maximize the value of the Product delivered by the Scrum team(s). The Product Owner’s most important tool for maximizing value is the content and ordering of the Product Backlog. As a result, most Product Owners spend a lot of time documenting Product Backlog items.
But that doesn’t mean that the Product Owner must personally document every item on the Product Backlog.
While the Product Owner remains accountable for the content and ordering of the Product Backlog, they may delegate the documentation of Product Backlog items to Developers on the Scrum team. For this reason, many Scrum teams may include members with business analysis skillsets.
Why is this?
There are several reasons. First, the Product Owner is a single person. The Product Owner is accountable for maximizing the product's value. How this is done varies from person to person. The Product Owner engages with stakeholders, developers, and the customer to determine what will add the most value to the Product. Depending on the amount of detail Developers need for items in the Product Backlog, it may be too much for one person to document every Product Backlog item, even for a single Scrum team.
But there’s more to it than that. In scaled environments, multiple Scrum teams may support a single Product. For example, if the Product is a large application, there could be three or more Scrum teams supporting it. Even when multiple Scrum teams work to support the Product, there is still only one Product Owner.
For example, I worked with a healthcare product team that had several Scrum teams supporting their application. All seven Scrum teams worked with a single Product Owner who was accountable for maximizing the product's value.
It would be unreasonable to expect a single Product Owner to write Product Backlog items for seven Scrum teams. The Product Owner in that situation would be more strategic, focusing on the vision and the high-level decisions about what to do next, but would delegate the documentation of individual Product Backlog items to the team.
Why it’s beneficial to delegate
The Product Owner accountability is accountable for the content and ordering of the Product Backlog, but it doesn’t mean that they can’t delegate. Below are the benefits of delegation for the Product Owner.
Focus on the bigger picture: Delegation allows the Product Owner to focus on the bigger picture and ensure that the Product is maximizing customer value.
Faster Iterations: Delegating documentation tasks to developers can expedite the process of refining and prioritizing backlog items, leading to quicker iterations and faster delivery of value to customers.
Enhanced Collaboration: Involving developers in the documentation process fosters better collaboration and alignment within the team. Developers gain a deeper understanding of the product requirements and can provide valuable insights during backlog grooming sessions.
Improved Clarity: Developers who are closely involved in documenting backlog items can ensure that the requirements are clearly articulated and easily understandable. This clarity reduces the likelihood of misunderstandings and promotes smoother development cycles.
Ownership and Empowerment: Delegating documentation responsibilities empowers developers to take ownership of the Product Backlog and contribute directly to its refinement. This sense of ownership motivates team members and fosters a culture of accountability and commitment.
Flexibility and Adaptability: Delegating documentation tasks allows the Product Owner to adapt to changing priorities and focus on strategic decision-making. By distributing workload among team members, the team becomes more flexible in responding to evolving customer needs and market dynamics.
Conclusion
While the Product Owner’s most important tool for maximizing the value of the Product is the content and ordering of the Product Backlog, they may still delegate the documentation of individual items on the Product Backlog to Developers on the Scrum team. It doesn’t mean the Product Owner is washing their hands of responsibility; they remain accountable and should stay engaged. Even when the Product Owner delegates some documentation to developers, the Product Owner should collaborate closely with developers to ensure that the content and ordering of the Product Backlog maximize customer value.
Want to learn more about Scrum? We hope to see you at this year's annual Scrum Day conference in Madison, Wisconsin.
I'd argue the most impactful tool a PO have on their hands - to influence the value created from the work on their product - is creating a collaborative environment (set up time & space, invite the right people) where Developers collaborate with users & customers on their wants and needs. The product backlog in Scrum should facilitate decision making: what problem/opportunity to tackle next. When the product backlog tries to facilitate any type of communication, we're adding a lot of waste and slowing the process down, ie decreasing agility! (Communicating is best done in person with plenty of whiteboards or similar visualization aids!)