Agile

The Product Owner Role When Scaling Scrum

Tuesday, February 23, 2016

A Scrum team is made up of a Product Owner, development team and Scrum master. This model works incredibly well at the team level. But what happens to the Product Owner role when we scale up?

Product Owner at the Single Team Level

The Scrum guide is a model of precise and clarity. In only 17 pages (16 if you exclude the end note and acknowledgements) it describes, the roles, events and artifacts of Scrum as well as the rules that bind them together.

With regard to the Product Owner, it says “The Product Owner is the sole person responsible for managing the Product Backlog.” and "The Product Owner is one person, not a committee.”

Victim of It’s Own Success?

For a single Scrum team, these role requirements present no problems. But spurred on by positive results from these teams, organizations want more. The obvious way to get more is by adding Scrum teams, right? Possibly, but please don’t consider this option if you’re behind schedule. All you’ll do is reinvent an agile variant of Brooks’ law.

Organizations have been grappling with scaled Scrum for years. There are a number of proposed solutions out there. Most of them share the view that when it comes to the Product Owner, we have one per product. Not one per team. As I say in my Scrum classes “There can be only one!” Cue 1980’s flashback and the film “Highlander”.

But this presents a problem. One Product Owner working with one team is easily achievable. But how do you scale the Product Owner role when you’re working with three teams or more?

Delegation & Automation

Scrum is no silver bullet. It’s a framework upon which we layer our chosen tactics and techniques. One technique that has stood the test of time, and is inherently agile, is delegation. We trust and empower others to take action on our behalf.

Examples of successful delegation abound:

- Organizations have only one leader. They bear great responsibility and cannot do everything themselves. They have to delegate work to others.

- Armies have only one General. With lives at stake, army generals bear probably the greatest responsibility of all. They cannot guide the work of every soldier in a battle. They have to delegate that work to others.

In our Scrum context, the Product Owner has total responsibility for their product. When they delegate their work they have to be mindful not to try and delegate their responsibilities. This means that we don’t create roles like “Assistant Product Owner” or “Chief Product Owner.” Instead, we delegate some of the work that a Product Owner might do. For example:

- Writing product backlog items: usually best done by the development team.

- Posting and maintaining the product backlog.

- Provision of value estimates for product backlog items – usually best done by stakeholders or customers requesting the feature(s).

Another way to lighten the workload of the Product Owner is through automation. We bake some of the Product Owner’s tasks into the product. For example:

- Create an easy-to-use online feedback/suggestion form integrated into the product.

- Automate reporting on key usability metrics from the logs to identify trends in what people are using the most and least.

- Open up feedback/suggestion/reporting tools to the entire team and involve it more in creating PBIs.

Summary

In a nutshell: When scaling Scrum, be mindful that a single product may well have multiple teams working on it but it still has only one Product Owner. To ensure that the role can scale successfully, we invest in delegation and automation to lighten the Product Owners work load, while maintaining their overarching responsibility for the product.

If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.

Read more: http://webgate.ltd.uk

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.