By Nick Butler
Tags: Agile
Yesterday I went to see Shane Hastie’s presentation on product ownership and the idea of the product ownership team. It was interesting to meet some of Wellington’s agile coaches and I enjoyed the presentation a lot. Having said that, I was a bit surprised that some of Shane’s ideas didn’t cause more controversy. Having just moved to NZ two weeks ago, I kept my questions to myself at the time. But having had a longer think about it there are some thoughts I’d like to express.
The main topic of Shane’s presentation was the idea that you need a product ownership team rather than a single person.
He started by asking the audience what they think the problems with product ownership are. I didn’t take notes, so I don’t remember all the answers, but here’s a few:
I agree that some of these issues are serious and have to be dealt with. It is natural to start tinkering with the process and it’s a good thing to do. Instituting a Product Ownership team though will probably not solve the problem, but may make it worse.
I’ve seen those symptoms before and most of them were attributable to a bad or half-hearted Scrum implementation.
Shane used the backlog as an example of why he thinks one person must be overwhelmed by the role of Product Owner. He referred to the Scrum Guide where it states
“The Product Owner is the sole person responsible for managing the Product Backlog.”
The problem with this quote is that it is a bit out of context. In the next paragraph the Scrum Guide states:
“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”
For the sake of the discussion I’ll ignore this part of the guide:
“The Product Owner is one person, not a committee.”
As the guide says, the PO is the one accountable for the backlog. But that doesn’t mean he/she has to do all the backlog refinement alone. I know companies who keep their backlogs completely open, so that everyone can pitch in new ideas. What the Scrum guide says though, is that one person has to be accountable. As it is the Product Owner who is responsible for the success of the product, he/she has to be the one who prioritises the stories. When in doubt which feature is more important, the Product Owner can talk to stakeholders, ask the development team for their opinion and so on.
Shane is certainly right when he says that being a good Product Owner is not easy, because you need to have a lot of skills. Here’s an overview from the presentation.
Although I agree with most of the skills listed on this slide, I don’t think that the Product Owner needs to know about UX and graphic design. I’ve seen Product Owners with UX skills spend a lot of time on upfront design instead. I’d rather let the development team figure out a good UX solution which of course requires having a UX designer in the team. Also I’ve not yet met a Product Owner with legal or compliance knowledge, but they have all managed to deliver successful products regardless.
So let’s take a closer look at what Shane proposes:
Some further thoughts I had during the presentation:
For me first and foremost, a good Product Owner needs a vision, good communication skills and a good understanding of his or her role and responsibilities. He/she should know whom to talk to when there are open questions and be there for the development team when they have questions. Does that mean we need a Product Ownership team? I’m not convinced.
What’s your opinion?
Want to know more about the product owner role? Check out these posts:
How to maximise your impact as a Product Owner on a Scrum project.
