A good product backlog is the key to any successful Scrum project. In this e-mail interview, Mike Cohn gives some good advice on how to succeed as a Product Owner.
We all know that the main responsibility of a Product Owner in Scrum is to create, prioritise and groom the Product Backlog based on Business Value. What are the most important part of this responsibility?
Once or twice a month I receive an unsolicited email from someone saying, “Scrum had been working pretty well for us; not great yet, but good. Then we started to pay more attention to our product backlog and, wow, then things really improved.” The importance of having a good product backlog cannot be understated. That’s what drove me to write User Stories Applied for Agile Software Development. And it’s why I insisted to my publisher that the book not be put in the XP series, as was initially planned. User stories are a very broadly applicable technique. Years ago I started to notice that the Scrum teams I worked with that invested time in their product backlogs had an easier time with many other aspects of the project. When I came across the Extreme Programming idea of user stories I instantly wanted to apply that to the Scrum product backlog. So, making sure the team has a good product backlog – even if it’s only roughly prioritized initially – is probably the most important responsibility of the product owner.
When finding a suitable Product Owner, which traditional roles are best suited?
The product owner needs to be someone with a deep understanding of why we’re making the product. In a commercial product setting that means someone with a deep understanding of the market. That means the product owner will usually be someone from the marketing or product management groups. In an in-house environment the product owner usually needs a deep understanding of how the internal users work with the system. In those cases the product owner usually comes from the ranks of the users or perhaps their managers.
What are the most important tools (not SW tools, but rather methods, disciplines, etc.) at hand for the Product Owner?
Product owners need good decision making skills and they need to use them. When a team is moving as quickly as a good Scrum team can move, they need product owners who can be decisive. Product owners also need good leadership skills. Teams look to their product owners for vision and so they need to be able to pass that along in a compelling manner. If we go back to the original article on Scrum, “The New New Product Development Game,” back in 1986 in the Harvard Business Review, the authors wrote that management’s role is limited to providing “guidance, moral support, and money.” Product owners are responsible for much of that – particularly the guidance. Personally, I like product owners to have solid financial analysis skills. I consider that necessary to make good decisions about priorities on the product backlog. In Agile Estimating and Planning I’ve written about non financial techniques that product owners can use to prioritize a product backlog, but I’d still want a product owner to have the basic financial analysis tools at their disposal. These aren’t hard to learn – I’ve taught the skills to many product owners in an afternoon.
The Product Owner is the owner of the Product Backlog and sole responsible of putting priority to the product backlog items. This is usually easier said than done, especially when other stakeholders get involved and have opinions. What good ways can you recommend for Product Owner to deal with different stakeholders?
I like any technique that breaks the problem up into smaller pieces. If you go to a group of stakeholders who have different goals (often motivated by competing financial incentives put in place by the company) you will not get satisfactory agreement if you start with “What’s the most important feature? Then what’s the second-most important feature?” Instead if you break the problem down into smaller discussions that can work. Start by identifying the handful of most important factors in planning the release – things like contribution to Q2 revenue, features of interest to enterprise customers, and so on. Then for each theme, or collection of user stories you’re considering, ask relative questions like “Which of these two possible themes contributes the most to Q2 revenue?” That’s the type of question where you can typically get people to agree. Then it’s a matter of having a way of looking at the collection of answers you get. There are various ways to do this such as theme screening, theme scoring and relative weighting that I covered in Agile Estimating and Planning. Another approach is analytic hierarchy process but that’s more involved and doesn’t scale particularly well.
How can the Product Owner best involve the Scrum development team in grooming the backlog?
At the start of a significant new effort (not every sprint) hold a story-writing workshop. This is a session where the entire team is invited to join the product owners and ideally some users or customers in writing the product backlog. This starts with the product owner describing her vision for the next few months to the team. In a semi-structured manner they then all write the user stories that will be considered. Starting out like this engages the team right from the start. Following that up by making sure that user stories on the product backlog are estimated so that they can be prioritized keeps the backlog visible to the team. Then occasionally work with assorted team members to split medium and large items into smaller ones as they move up the backlog and then need to be small enough to complete in one sprint.
