Best Practices for Becoming a Better Product Owner

It may be that your organization is just beginning its Agile transformation or has yet to begin. It's also possible that it's been going on for some time but that you just haven't made the forward progress you'd hoped for in terms of software releases or customer responsiveness.

Whether you're at the beginning or in the midst of trying to bring about change, one of the most significant challenges I've seen for Agile teams is dealing with a Product Owner who doesn't fill all the roles that a Product Owner is expected to play.

For starters, what role is the Product Owner expected to play?

Well, according to Jeff Sutherland (co-creator of Scrum) and J.J. Sutherland (Chief Product Owner of Scrum, Inc.), the Product Owner:

" … [needs] to spend half their time talking to the people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing what the customer valued and what they didn't)."

This is a relatively tall order all by itself — a Product Owner needs to spend half of their time with customers and half with a software development team.

But even beyond the basic challenges, there is simply the matter of how to organize this work.

A Product Owner might already be doing that but isn't delivering everything that the team needs. Here are some best practices for becoming a better Product Owner:

1. Have a Storywriting Workshop

If you are trying to figure out how to improve the product backlog or fill it out more effectively — this is the tool you need to employ. A story writing workshop is an opportunity for a group of stakeholders: business people, leaders, and scrum team members to come together and add to the product backlog in a significant way.

Normal Frequency: Once per quarter.

2. Product Backlog Refinement

Already have a substantial backlog but it needs some help? Get in there with team members and work on it. Again, focus on the most important items. The expectation is that this work goes on during every sprint to make sure the product backlog is groomed and prioritized for future sprints.

Normal Frequency: Once per sprint.

3. Attend Scrums Regularly

The Product Owner is one of the cornerstones of Scrum. Attending regular team meetings and participating will show your dedication to the team, help your team better understand how you are preparing the backlog for upcoming sprints, and demonstrate your understanding of the process.

Normal Frequency: Every day or several times a week.

4. Define a Vision

You should have a vision for the overall product, and you should have a vision for your current release cycle. This should be larger than just what are we completing this sprint — unless your current sprint is the culmination of earlier work. It should define significant, challenging goals for your team to bring them together and keep them focused across a longer period of time — a fiscal quarter is a good goal. If you don't have a vision, what is holding your team together and setting them on a motivated path?

Normal Frequency: One time for the entire product, on a quarterly basis for major product goals.

5. Define User Roles

If you don't have clearly defined-roles for your users, you need to create them. Many projects start here, but if you are inheriting a product that has morphed over time or just never had them defined, spending a little time on clearly defining the roles for your system is worth the effort.

Normal Frequency: At the beginning of a project, one time when new roles are added.

6. Story Mapping

An additional technique to help with prioritization and being able to build toward a roadmap is the idea of story mapping. Story mapping can be done as a follow on to a Story Writing Workshop, or it could be done following a product backlog refinement. It is a helpful way to understand your MVP, prioritize, and make sure that you build a working product.

Normal Frequency: As needed

Taken all together this might seem intimidating, but keep in mind that each piece adds incremental value. Doing just one of these can make a significant difference.

The six best practices above are listed in the order that they should be acted upon (if they aren't already). For example, if a backlog is not defined or well-prioritized, the team is hamstrung — it is happening right now — they are not as effective as they should be and it must be fixed. Immediately.

In many ways, the Product Vision is the most important thing on this list. It is relatively easy to supply and the Product Owner should supply it. However, as with user roles, a team might already be working off of their own vision and can effectively work without the Product Owner supplying one for them. The team's vision may not be the same as the Product Owner's vision, which is something that should be fixed as soon as possible, but it is a less dire emergency than a backlog that is in need of refinement.

Product Owners have an especially hard time — often they come from the business, having had customer-facing jobs — and often they are asked to continue doing those jobs in addition to the job of being a Product Owner. This is challenging. Trying to tackle it all at once is hard, but by using the list above they can add incremental value and move more and more into the Product Owner role the organization needs.