The Scrum Guide says that a scrum team consists of three roles: product owner, development team and scrum master. My work as a scrum trainer and coach has revealed that some organisations don’t use product owners at all. So, are they really necessary?
Scrum Product Owner? We Don’t Need No Stinking Product Owner!
In the early part of my scrum career, I was contracted to work as a scrum master with a new team. The work was with a large UK eCommerce organisation. This organisation had no physical retail outlets. All sales were done via the Internet. They had experienced phenomenal growth and were still growing fast when I joined them. Exciting times.
Job one was to understand the basics. What I discovered unsettled me:
- Check the product vision – None available
- Review product backlog – None visible
- Meet the product owner – No-one knew if there was one
- Meet development team – Check! Great guys but we hadn’t started sprinting yet and no-one knew what we were going to be doing
So, not the best of starts. I set about trying to improve it. My journey led me to the PMO who told me that my product owner was Matt (not his real name). I went to find Matt. To cut a long story short, the conversation showed that:
Matt was a project manager working with the PMO. He was put in the product owner role. No, he’d had no training. No, he had no budget. No, he hadn’t created a product backlog. No, he had no authority over the work that the development team would be asked to do. No, he’d never worked as a product owner before.
I worked with Matt to help him in his new role. He was keen. I worked with the organisation to encourage a more professional attitude to product owners. They indicated their indifference. I probed further and had a conversation with one of the first coaches to appear on the contract. What she said shocked me : The client had made a clear decision to adopt scrum but not to utilize the role of product owner. That would be handled by the PMO instead.
The only good thing I could say about this was that I had a front row seat in what happens when you try scrum without a product owner. It’s not pretty.
What surprised me about the situation was this: The organisation had made a multi-million pound investment in scrum. At the same time, they decided to ignore decades of experience from other organizations that had adopted scrum. This astonished me. But, perhaps what makes it worse, is that this situation is not unique.
Putting a Sticky Plaster on a Suppurating Wound
Here’s just one of the many symptoms that the absence of a product owner revealed.
The PMO was frustrated by the lack of control and understanding over the progress of scrum teams. In scrum, the product owner handles this but of course, we had none. The programme manager called a weekly meeting that involved the scrum master and two developers from each of the 12 teams. A minimum of 37 people in each meeting.
The meeting was set for 1.5 hours. No agenda was published. In reality, the meeting over-ran considerably.
I decided to examine the cost of this meeting. I discovered that the annual cost would pay the salary for 3.4 product owners.
This one act alone was costing the organisation heavily. It was a financial impediment and a scrum impediment. And this was just one example of a scrum anti-pattern caused by the lack of a product owner.
What Does a Product Owner Do?
The definitive answer to this question is in the scrum guide. However, the best description I’ve seen of a product owner is ‘mini-CEO’. This description implies that the product owner has financial authority, responsibility for the work of the development team and TCO and ROI for the product. The implication is correct.
That’s a lot of power and responsibility to invest in one role.
Is the Product Owner Role too Powerful?
Maybe that’s the core of the problem. Organisations don’t want to hand that much power to one individual. But then, that same level of power is invested in a role like programme manager. So, maybe the real reason is that organisations don’t value a product owner as much as a programme manager?
I don’t know the answer to that question. Each organisation is different and each will have their own reasons for not adopting the product owner role. What I do know, is that a good programme manager can make a good product owner. It just takes a bit of training and maybe some coaching.
How many Product Owners are There?
There’s no way to know how many product owners are out there plying their craft. But maybe we can examine a ratio of scrum masters to product owners. It’s seems reasonable to assume that they should be roughly equal. Let’s look at how many certificates have been issued (in this case, by Scrum.org. Accurate at the time of writing this article):
- Scrum master certificates issued : 29,833
- Product owner certificates issued : 3,617
Put another way, for every 10 scrum masters, there’s one product owner. It seems that we’re keen to learn the rules of scrum and get advice on how to play. But we’re less keen on the role of product owner.
Here’s what the scrum guide says about the product owner role:
The product owner is responsible for maximizing the value of the product and the work of the Development Team.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
That’s a lot of responsibility. Implementing the role takes courage from an organisation. Adopting the role takes courage from an individual. But the benefits of scrum are there for the taking. Take courage. Invest in your people. Help your scrum implementation succeed.
Spread the Word
If you see value in this article, why not share it? Use the social media buttons below. It takes a moment and your karma levels get a boost. On the other hand, if you thought the article was drab, why not drop me a line? I welcome all feedback.