In 2009 I first published Scrum Product Ownership. In 2013, I followed it up with a second edition. The book has been a popular read for those who are looking for a solid overview of what it takes to be a competent and craft-focused Product Owner.

Here’s what a new Product Owner from Spotify had to say about the book:

“I was recommended your book “Scrum Product Ownership – Balancing Value from the Inside Out” by senior colleagues at Spotify as the one book to read when new to product owning. After recently finishing reading it, I fully agree and will keep recommending your book to anyone getting started as a product owner.

I just wanted to say thank you for making the start of the ride less bumpy and for great advice that I will keep returning to as I gain experience.”

I share this because it helps to set the stage for this article and where my inspiration lies.

Product Owner Assessment

When I published the second edition, I also released an assessment framework for the role of Product Owner. The framework is loosely based on Bill Kreb’s Agile Journey Index, which I wrote about in .

In this article, I want to explore the categories of focus for the assessment tool. I’m sharing as a way of either:

1. Inspiring you to use the tool in assessing your Product Owner organizational maturity OR
2. Leveraging it to construct your own tools for measuring you Product Ownership maturity

In either case, my hope is to give you a framework to get you thinking about the dimensions of what good looks like, when it comes to Agile/Scrum Product Ownership.

Why?

So that you have a baseline of practices, techniques, or approaches that are important for a well-rounded and balanced Product Ownership practice. Not for grading or comparing one PO against another. Please don’t do that.

But simply as a tool for establishing what good might look like in your organizational context and then using it to drive continuous learning and continuous improvement across your Product Owners.

There are four areas where I have gathered what I consider to be crucial Product Ownership practices:

1. Table Stakes
2. Basic Practices
3. Communications
4. Steering

Next we’re going to explore each area in turn – examining the practices within each in high-level details so that you get a feel for the overall assessment framework. If at the end of the article, you’re intrigued and want to learn more, then I’ll share how to get more details on the framework.

Let’s get going…

Table stakes are just that – things that you should be investing in right at the beginning. First is the investment in Product Ownership, or more specifically, Product Owners in your organization. Do you have a PO per team and is it their primary responsibility? Often organizations struggle with the move to Scrum because of the initial “investment” in Product Owners and Scrum Masters. But it’s this very investment that’s a table takes item.

Next we’ll explore one of the most prevalent requirement artifacts being used in agile teams – the ubiquitous user story. They have become an incredibly popular way to craft agile requirements, but beyond the stories, they illustrate the elements of agile requirements in general. That is that they’re essentially just-in-time and ambiguous in nature. They are essentially intended to evolve until they are delivered and the Product Owner is a shepherd of the stories.

And the final table stakes element is the Product Backlog. There’s an incredible amount of confusion surrounding this simple list of “things to do”. Is it requirements/stories or something else entirely? For example, is it the beginnings of a plan for your release? The short answer is that it is – what it needs to be in order to effectively guide the teams’ deliverables. And the Product Owner is the head guide.

Product Owner

• Do you have one? Do they have the training, skill and understanding necessary to do the job?
• What about domain experience? And organizational experience?
• Do they have sufficient time to invest in their role? Both the inward and outward components.
• Are they empowered to make business decisions and effectively guide their team?

User Stories

• Are you even using lightweight user stories or do you continue to hold to traditional, heavy weight requirements?
• If you’re using stories, do you understand the “three parts” of a user story and how to write them well?
• Do you have the notion of entry or readiness criteria?
• And are you heavily investing in acceptance criteria as a means of communicating the business “what” and “why”?

Product Backlog

• Multi-faceted prioritization between the business, team, and technology needs?
• Does the Product Owner ‘own’ the backlog or does the team?
• Is backlog refinement actively occurring and are stories being examined 3-4x as they evolve towards being executable?
• Does the Product Owner do sufficient longer term look-ahead so that the team understands “where they’re going”?

Clearly the Product Owner doesn’t play a direct role in team estimation. However, they foster an environment via backlog refinement, where the team estimates backlog items. But beyond the teams’ estimates, their participation can give them all sorts of insights into level of complexity and level of effort for the types of features they’ll be asking the team to deliver. This information can easily be factored into product strategies and workflow.

Valuation (prioritization) is one of those areas that I’ve found to be really hard. Most Product Owners are intelligently guessing, with their stakeholders, around what the customer really needs. More deterministic approaches for feature valuation, and importantly, measuring usage post-release, are often non-existent. I’d separate these challenges from trying to take sufficient time in effective prioritization from multiple perspectives – customer, team, and technology.

And finally, goal setting is one of those under focused activities within many agile teams. Which is unfortunate, because it’s ultimately how you “drive results” from your team. Not by telling, but by painting a vision and setting goals for them to envision and achieve. In traditional organizations, goals typically come from “management”. In the agile organization, this responsibility lies with product ownership. And these are expansive or inclusive sorts of goals. For example: yearly roadmaps, quarterly release objectives, release feature lists, and down to the level of individual sprint goals.

Whether you acknowledge it or not, product ownership is largely a factor of setting goals for your teams to achieve and then measuring goal achievement at the end of iterations.

Estimation

• Avoiding non-team based or management/leadership based estimation of any sort. Instead, looking to the team for lower level estimation (stories sized for sprints) and higher-level forecasts.
• Leveraging one of the whole-team estimation practices (for example: Planning Poker) as a means of collaborative estimation. Consistently fostering an “all voices” style in estimation.
• Allocating time and space for sufficient story spikes to determine true size and scope instead of the work. This could be for technically and/or business functionally complex items.

Valuation

• Have a balanced strategy for valuating (prioritizing) the Product Backlog that includes business, customer, and technical drivers. Involving stakeholders directly in the process (value poker).
• Unafraid to break down elements, minimizing scope to increase experimentation, speculation, and fact-finding to increase understanding of value.
• Release criteria contain ROI measures that have pre-release goals and post-release actuals. Learning and adjustments are made based on real team results and retrospective feedback.

Goal-Setting

• Firstly, do you consistently have goals both at a sprint and a release level? Are the clear and well understood? Have you engaged the team in making them feasible and reasonable?
• I consider the Definition-of-Done to be a unifying goal of sorts connecting the team’s work to stakeholder expectations.
• Is goal attainment something that’s kept hidden or obfuscated or is it full transparent. And how much “wiggle room” have you built into the goals so the teams have flexibility to be innovative and creative?

Wrapping Up

That wraps up the first two of four critical areas when evaluating your Product Ownership capabilities. In the next/final installment of this article, I’ll cover the last two areas.

The intent of this 2-part article is to expose you to my AJI-extensions for Product Owners. Remember it’s a framework and intended for healthy improvement of your practices.

Not only am I hopeful that I made you think about Product Ownership maturity, but I hope I inspire you to .

And not only to download it, but also to read through it and to possible use it in your organization.

And please remember, this is an iterative framework and I’m constantly learning and adjusting it. If you use it and have feedback towards improvement, ANY FEEDBACK, please take the time to send it to me. I promise to carefully consider it and incorporate it in the next edition of the framework.

Stay agile my friends,

Bob.