Skip to main content

The Agile BA: Moving Beyond “The Backlog” – The 4 Quadrants of Product Ownership, Part 1

When I say “Product Owner” to you – what do you think of? And when I say “Product Backlog” to you – what do you think of?

I ask these specific questions all of the time in my classes as a means of introducing basic agile topics and gaining a feel for the level of experience of the attendees. There’s usually a relationship between the two answers.

The common answer to the first question is: The Product Owner ‘owns’ the Backlog. So, what is the ‘Backlog’? The second answer is usually a list of attributes:

  • It’s a list of things to do
  • It’s ordered by priority or business value
  • It’s sized by the team
  • It has varying sizes of work items
  • Early items or more finely grained than later items

All of which are created by the Product Owner for the teams’ consumption and delivery—since the Product Owner…’owns’ the Backlog. Let’s extend the discussion a bit by sharing the current definition of the Product Owner role by Ken Schwaber and Jeff Sutherland in their Scrum Guide:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. 

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;
  • Ensuring 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 may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

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 backlog item’s priority must convince 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.

This is what I mean by having a “the Backlog” view or mentality when it comes to Product Ownership. It’s far too simplistic and revolves almost totally around the backlog. And while that is indeed a large part of the role, it does the role a disservice by being far less nuanced than truly needed.

In my book on Product Ownership, I speak of 4 key areas that a Product Owner must focus on to perform well in the role. They include:

  1. Product Management;
  2. Project Management;
  3. Leadership;
  4. Business Analysis.

I like to characterize these areas as “quadrants” of the role and responsibilities that lead to effective and solid Product Ownership. In this 2-part article, I want to explore each quadrant in more detail—broadening and adding nuance to each, and therefore to the overall role.

Quadrant1: Product Management

The first quadrant of the role is one of classic Product Management. I’ll reference Pragmatic Marketing for help expand this quadrant. This is the outward-bound part of the Product Owner role, the one that dialogues with stakeholders and investors to sort through the vision and the roadmap for a product. They are the ones who run focus groups and interview real-world customers to determine their problems and challenges. Then they help create innovative product-driven potential solutions to those challenges and problems.

Another part of this quadrant is serving as a product champion. Quite often Product Owners are in the very best position to demonstrate the product. They understand the workflows at a high level and can quickly run through the critical functional scenarios. They’ve probably worked in the problem domain, understanding customer challenges, and are creatively trying to solve those problems.

Still another part of this quadrant is establishing a product mission and vision. Often they establish a release roadmap with key stakeholders by gathering everyone’s vision and then aggregating it into a cohesive whole. Quite often these roadmaps lead to release milestones and customer commitments, which need to be managed as each release of the product unfolds. This part of the quadrant connects quite nicely with the execution bits you’ll see in the next quadrant (Project Management) discussion.

There’s also a true Marketing aspect to the role—pulling together functional overviews and whitepapers that explain the product and help the sales team. This would also include other types of collateral, including pricing and ROI models, while preparing sales channels for a successful kick-off or release. So there is a strong connection from thus quadrant to the organizations sales and customer support functions.

Nowhere in this quadrant did I speak about the Agile or Scrum team. This quadrant is truly externally facing, either toward internal stakeholders or towards the outbound customer. One final point, if you have Product Managers as a role within your organization, it is often a full-time role within itself. That can create quite a disconnect when introducing the role of Agile Customer or Scrum Product Owner, in that now you’re adding more responsibility on top of a potentially overloaded role. Watch out for this when you’re deciding whom to select as your Product Owners.

Quadrant 2: Project Management

This is the quadrant that receives possibly the most pushback when I present it. Everyone has a picture in his or her head of a traditional software project manager and they simply don’t connect it to Scrum Product Ownership. So what does project management have to do with the role?

I’m glad you asked. I think a good place to start is by envisioning the Product Backlog not simply as a prioritized list of requirements, but something more. You see the backlog is the one artifact in agile teams that captures the features, the work, the flow, the risk, etc.; it’s essentially a Work Breakdown Structure or WBS for agile projects. Given this, I think a healthy backlog is a place for traditional project management activities, for example:

  1. With the team, taking a “step back” from a sprint-by-sprint focus and looking for the most effective way to deliver on a releases’ goal(s).
  2. Early on, aligning stakeholder expectations on content with each team’s capacity and confidence in delivering that content.
  3. Establishing early architectural and design work that established a framework for supporting the content in the release. This is not BDUF, but LDUF .
  4. Embedding testing activities and strategies in the backlog, particularly in high application integration or regulated environments.
  5. Sprinkling milestones (rallying points, integration points, demonstration goals) throughout the backlog that show how the team will be building functionality up towards their release.
  6. Ensuring that the team is considering all work that is required to take a customer-usable release from the concept phase and get it into the hands of customers for usage.

Release Planning

galenimg01 june11One of my early agile experiences was with Extreme Programming or XP. In our Meta-Cast the other day, Josh Anderson and I were discussing this quadrant and I mentioned this. 

One of the activities associated with XP was something called Release Planning. It was tightly coupled to User Story writing and creating a work list or backlog of items to work on. Visually, figure 1 represents the process. When I was doing it in the early days we would simply use masking tape to tape iteration “swim lanes” on a long conference table. Usually our releases were on the order of 10-12 iterations, so we would have quite a few lanes spread across the table.

The next step was to distribute the work, user story cards, across each of the iterations. Usually the team would do this. First they would take a ‘whack’ at laying things out very quickly first. Then they would hover around the table and start moving work (story cards) around.

Conversations would surface around the most effective way to deliver the functionality – workflow, around risk mitigation and unknowns, around dependencies and integration milestones. Quite often the discussion would drive a new user story that was added to the mix. Typically these were what I like to call “glue stories” or stories that support the stream of features or functionality.

After perhaps an hour or so, the team would feel they had a nicely balanced workflow leading to a release point. Quite often they couldn’t fit in what the stakeholders had envisioned for the time frame, so there would be some negotiation and scope trade-offs. But in the end, they formed a release plan that felt feasible.

It was at this point that the stories were collected in order and they became a “Product Backlog”. At this point, they began iterating or sprinting.

The Product Owner role is a central figure in Release Planning and Road-Mapping at these higher levels. They work with the stakeholders on needs and with the team on the reality of delivery. Release planning converges these two perspectives into envisioned, prioritized, high-value bodies of work that align with release expectations.

It’s primarily the iterative nature of these planning activities that make me think the Product Owner has a wee bit of Project Manager in the role—no matter how folks respond to what they think that role entrails on traditional projects.

Wrapping Up

I’ve covered two of the four quadrants in this article. In part 2, I’ll cover the remaining quadrants.

So far we’ve explored Product and Project Management activity within the Product Owner role. If we simply stopped here, it would be a full-time and challenging role to fill. However, there’s still more to explore. Next time we’ll explore the Leadership and Business Analyst quadrants.

I hope you are beginning to get a feel for the depth and breadth of the role. And perhaps a newfound respect for your Product Owners in general.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

Footnootes:

Scrum Guide, October 2011 version, except from page 5 
The firm Pragmatic Marketing has a wonderful framework that illustrates all of the aspects of typical, technical Product Marketing. It’s useful to reference this so you understand the depth and breadth of a Product Managers responsibilities.
In the agile methods there is a coherent warning against Big Design Up Front or BDUF. The problem is that you can’t adequately design anything without in code experimentation and implementation. So the agile methods come at this challenge with iterative architecture and design that is qualified by working code. LDUF is a healthier, iterative version—Lean Design Up Front. It implies a Just in Time and Just enough strategy. It also implies that your architecting and designing on the fly; proving your designs with working code whenever possible.
Click here to listen to our podcast: Josh Anderson and I co-host it. We’ve recorded 40+ open discussions where we chat about all things agile. There are several Meta-Casts where we’ve explore the role of the Product Owner and mentioned a quadrant-based view at the role and responsibilities. In Meta-Cast 40-41, we explore the quadrants in much more detail.