By Nick Butler
Tags: Agile , Development
You know Scrum specifies having a single Product Owner but you’re considering having more. To help you decide, this case study shows why New Zealand’s National Library went for multiple Product Owners and how they make it work.
The case study is part of our Product Owner primer series. It follows on from our ‘What is Scrum?’ and ‘Successful Scrum Teams’ posts.
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
The National Library is tasked with helping Kiwis capitalise on the collective knowledge of the nation. Within National Library, DigitalNZ was set up to make New Zealand’s digital content easier to find, share and use.
Both National Library and DigitalNZ have their own websites providing access to catalogues, collections, services and other resources.
Boost are the National Library’s development partner. We provide their Scrum Masters and Development Teams. They currently have two Scrum Teams. Each of these Scrum Teams has one Scrum Master, three or four developers and, contrary to Scrum doctrine, at least three Product Owners.
According to the Scrum Guide “the Product Owner is the sole person responsible for managing the Product Backlog”. The Guide is specific: “The Product Owner is one person, not a committee.”
That’s because having a committee reduces transparency and slows inspection and adaptation. The Backlog describes the priorities for the work but having multiple Product Owners can muddy priorities. With multiple Product Owners you have no single source of truth so it’s not always clear who to talk to. And a committee is less likely to give quick feedback, slowing work down.
“It’s very hard to listen to multiple voices,” says Rebecca Jones, Boost Scrum Master for our National Library work.
So if you’re going to have multiple Product Owners, you need to make sure you do it in a way that maintains transparency and aids inspection and adaptation.
National Library had more work than one Product Owner could manage and still spend time in the business. Spending that time gives Product Owners the crucial understanding of customer needs.
“If we had one Product Owner, they would spend all their time being a Product Owner, creating stories, sizing stories, doing refinement. Eventually, they’d become disconnected with the actual business that they were supposed to be the Product Owner for,” says James Robertson, DigitalNZ Systems Manager.
The National Library work had particular features that fed into their decision to use multiple Product Owners.
The DigitalNZ and National Library websites and tools already exist. In fact they are the product of literally hundreds of Sprints. The work now is more a continuous value stream than a discrete series of projects.
In a post on scaling the Product Owner, product ownership expert Roman Pichler says new products should have a single Product Owner but established products can need more. Young products need rapid decisions as you adapt to the large amounts you learn from getting them in front of customers. A single Product Owner is best-suited to this. Mature products grow and require more development than one person can stay on top of. At the same time, they tend to change less, and less often, reducing the potential drag caused by shared decision-making.
If you have a discrete pieces of work you’ll often want to split those off into separate projects. Indeed this is what the National Library did when they wanted to refresh their Any Questions website for example.
Because it’s an established project, the National Library have a team experienced in Scrum. When James started a few years ago the team had processes in place to make having multiple Product Owners work. But it would be much harder to set up these processes with a green team working on a greenfields project.
For the National Library, the current state of play involves two Scrum Teams. One of these is for the National Library site and services, the other for DigitalNZ. Both Scrum Teams have multiple Product Owners, each responsible for a different stream of the work.
Take the DigitalNZ Scrum Team for example. Product ownership is effectively split between three Product Owners like this:
“Having split Product Owners works because we have split the products clearly,” James says. “It’s quite clear to the team who’s responsible for which area, so there is never any question about who to talk to.”
If you have this kind of clear split, one option is to have one Scrum Team for each stream. The downside is that each team needs a Scrum Master and ideally at least three developers. This can cost more money. If you can afford it, consider this approach. You will need to invest a bit of time in coordinating the different teams but this should be less work than the constant coordination required when you combine Scrum Product Owners within a single team.
Here’s how the National Library have made having multiple Product Owners work.
Initially the National Library had one “super Product Owner”, what Mike Cohn calls a Chief Product Owner.
“He had oversight over all the different streams of work and would ensure that everything had appropriate level of business value relative to cost, and that we were getting the right blend of work from the different streams,” says James.
“He’d look at the backlog for the next sprint before it came out, discuss it with the various Product Owners, perhaps tweak the priority order, or question whether a story should be done now, or done at all. It was a way of managing that natural tension between different people wanting to get their own way.”
Then organisational responsibilities changed and this was no longer possible.
In order to continue giving each stream a fair share of the development effort, each Product Owner now has their own budget and they decide on the priorities for spending that budget.
Using budgets in this way is a bit of a blunt tool so the Product Owners have some flexibility to juggle the work.
Making multiple Product Owners work needs an extra level of coordination, communication and collaboration.
The National Library Product Owners discuss and coordinate their work internally as well as with the team.
“The Product Owners support each other as a team and put effort into working well together,” Scrum Master Rebecca says. “Because they work very closely they understand each other’s priorities. They’ll talk about it as a group first and decide what the overarching business priorities are before they push their own work.”
“You have to be a bit adaptable,” James says, “you have to understand that you’re not the only king in the room.”
You do spend some time twiddling your thumbs in meetings while the other Product Owners discuss their work with the team.
“That’s a pretty minor downside,” he says, “and the advantage is that the Product Owners are aware of what other work is going on.”
James also says it’s best if you don’t weigh in too often on work for the other Product Owners.
“Learning to bite your tongue is reasonably important,” he says.
Like Boost, the National Library team are mainly in Wellington, but some of the Product Owners are also based in other cities.
“The extra communication’s made fairly easy by the online tools that we use, like Slack and appear.in.” James says.
A lot of this collaboration happens naturally as a result of all the Product Owners coming along to all the Scrum Events.
Along with Sprint Planning and Refinement, Retrospectives and Reviews, they all also join the Daily Scrum. For those in Wellington, this often means appearing in person. For those outside Welly, it’s via video conference.
Both Scrum Teams come together for a combined Review. This gives everyone insight into the all the work and offers additional perspectives for feedback. It’s also a chance for the whole crew to celebrate the impact the teams have had, the benefits delivered to the National Library and the people of New Zealand.
Knowing that face-to-face communication works best, the Product Owners are also looking to spend more time in person here at Boost.
Because the Product Owners also work in the business they’re not full time. That means they have to make a special effort to be available, to check stories that are up for acceptance and to respond to questions. It’s a bit of a juggling act.
For the National Library work we use Pivotal Tracker as our digital tool for managing the Backlog, along with a physical Scrum board. We have a single Backlog for all the work of each of the Scrum Teams, meaning each Backlog contains stories for multiple Product Owners.
Each story specifies which Product Owner was the Requester so the developers always know who to talk to about the story.
Tags on the stories identify which budget stream will be billed.
Spreading stories amongst three streams might make it harder to deliver a potentially shippable product.
For this work, most stories deliver value straight away. That’s because the Definition of Done means that each story is fully tested and integrated into the existing project, and because few of the stories are dependent on other work to be released.
When one stream has a chunk of work that can only deliver value if a number of large stories are completed in a Sprint, the Product Owners can juggle the amount of work for each stream to enable this.
The Product Owners get additional benefits beyond being able to spend time in the business:
With extra Product Owners, everyone has to work extra hard to keep meetings within their timeboxes. Having multiple Product Owners can also affect different team members in different ways.
While Product Owners can specialise, a cross-functional development team needs to be able to work on all the streams.
“Having three different streams getting fed through one team means there’s quite a lot of context-switching for people, which can be a challenge for efficiency. Some devs prefer to get in the headspace of just one type of work and stick to that for at least a Sprint,” James says. “Other devs have said the opposite, that they actually enjoy the variety.”
“Within the team, they have the opportunity to manage themselves. If one person feels like they’ll benefit from working exclusively on this stream of work, then as long as their teammates are happy with that, then we’re happy with that.”
Rebecca has found very few issues as Scrum Master.
“It’s just a couple more relationships to build, a bit more admin, just making sure that everybody can attend the meetings,” she says. “It’s also harder sometimes when Product Owners are remote, making them feel engaged.”
“It feels like we’re one team,” she says. “That’s because I trust that they trust each other.”
You should probably think again.
Often organisations are tempted to have multiple Product Owners for reasons that don’t fit with the Scrum framework, such as giving stakeholders a say in the work.
“Ask yourself, ‘Do we absolutely need multiple Product Owners?’. I would say most of the time you don’t,” Rebecca says.
But if you can’t work without having multiple Product Owners, we hope this case study helps you do it in a way that gives the impact you’re looking for.
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
In New Zealand and keen to get to grips with Scrum and the Agile mindset? Check out our Agile training:
Agile Professional Foundation certification, Wellington, NZ – two-day ICAgile course
Introduction to Agile methodology, Wellington, NZ – free two-hour workshop
Agile Accelerator team assessment – Agile review and action plan
Scaling the Product Owner role — Roman Pichler
The Chief Product Owner on Large Agile Projects — Mike Cohn
Product ownership is a team sport — Boost blog
The Product Owner’s guide to working with developers — Boost blog
From good to great product ownership — Boost blog
