7 Ways to Effectively Manage a Product Owner Backlog

Product backlog management is an art form that requires relentless attention. As a Product Owner, it’s your responsibility to run a well-oiled machine and keep the product backlog healthy. This includes accommodating stakeholders, development teams, and most importantly, users. But how do you manage a product backlog in a way that is effective and results-driven?

Here are 7 tips from an Agile Product Owner who’s been around the block:

1) Order the Product Backlog for Clarity

The order of the product backlog is a top concern. It’s how you explain the intended path of execution to the development team and stakeholders, which is a moving target for a Product Owner. It also keeps you organized, makes finding and discussing product backlog items easier, and clears up what your target is ‘today.’ The question that then arises is, how do you determine the order?

The product owner backlog should be ordered by value, with value being relative to the product that you’re building. We’ll dive into this concept next.

2) Focus on Value Above All Else

If something doesn’t deliver value, then it shouldn’t be in the product backlog. It’s simple. The product backlog isn’t a comprehensive wish list of every idea that people pass on to you. Be intentional about what goes in the backlog. If it doesn’t have value, that’s your cue to remove it.

As the Product Owner, it’s your job to justify why something’s valuable or not. A great way to do this is to come up with a system that estimates the business value of Product Backlog items and be consistent in your approach. Richard Hundhausen of Accentient suggests how you can numerically estimate business value to keep your eyes on what’s important.

3) Understand Dependencies to Dodge Impediments

There will always be dependencies on product backlog items in the form of technical constraints, business decisions or other Scrum teams. It’s up to the Product Owner to be cognizant of dependencies to ensure fluid Sprint Planning sessions and help teams avoid impediments during a Sprint. One way to do this is by sticking to an appropriately ordered product backlog, as outlined in tip #1. Word to the wise: Don’t fall into the common trap of trying to use a tool to track every dependency. In my experience, that ends up being much more work than it’s worth.

4) Get Feedback and Reflect

There are three constituent groups that a Product Owner must appease: the development team, stakeholders, and users. A product backlog must reflect outcomes of conversations from each of these groups, and the Product Owner must be transparent about those outcomes. Product Owners should do the following:

    • Engage development with cadenced, time-boxed backlog refinement sessions.
    • Schedule time with the appropriate stakeholders and seek them out if they had input at the Sprint Review.
    • Be creative in how you get into the mind of your customers.

Transparency is key to ensuring you’re heading down the right path in terms of what you’re developing, how you’re doing it, and for whom the product is being made.

5) Find Your Peace in Emergent Requirements

Requirements on an Agile project are emergent, meaning that we uncover the details of high-level features progressively rather than upfront before development starts. There’s no large upfront requirements phase where we assume dark corners of a project have been discovered. Instead, we solicit a high-level list of requirements from the customer, prioritize them, and refine top priority items as we progress.

Emergent requirements minimize upfront requirement gathering efforts, allowing us to quickly and efficiently change course and mitigate the risk of making incorrect assumptions. Avoid diving into every detail of each requirement and please don’t end up regressing into iterative waterfall. Likewise, remember the intention of a user story is to be a conversation piece not a contract.

6) Stop Thinking Estimates are Perfect. You’re Human.

There’s a movement to stop estimating in Agile. Why? Because humans are terrible at estimation and we shouldn’t spend a lot of time on it. Instead, techniques like poker planning or affinity estimation allow Development Teams to quickly forecast a product backlog. This will help you to negotiate scope with the masses and will appease stakeholders with a date.

Don’t forget, however, that estimating is an imperfect science, so don’t scorn the development team if things go awry. Just work to better recognize when things are going wrong as early as possible.

7) Implement Layers of Decomposition

You need a few layers of decomposition in your product backlog to have a high-level conversation about the state, scale across multiple teams, and to focus on incremental delivery. Popular tools come built-in with the ability to do this.

Depending on your organization, terminology may vary but your layers of decomposition should include objective, feature, and user stories. Here’s an example:

    • Objective – Increase web checkout transactions by 5%
        • Feature (Epic) – Personalization
            • User Story – Retain Retaining Customer Credit Card Info
            • User Story – Frequent Visitor Discounts
        • Feature (Epic) – Expand Payment Options
            • User Story – Accept PayPal
            • User Story – Add Bitcoin
            • User Story – Gift Cards

These layers allow for easier conversations and give greater power in ordering a product backlog as ordering may happen at any layer. You also want to think incremental delivery and do your best to deliver small chunks into production.

As a Product Owner, a refined backlog is a major step in incremental delivery and producing a winning product your team enjoys developing and your customers love using. Are you setting your development team up with a full tank of gas to drive a Sprint into an Increment?