As the singular prioritized list of desired work for your Agile team, the health of your product backlog reveals — more than any single artifact in Scrum or Kanban — your ability to deliver business value in the face of constant change. Skillful management of the product backlog starts with being aware of five common mistakes that can prevent you from motivating your team, engaging stakeholders, and achieving success.

Mistake #1: You Treat Your Product Backlog as Your Technology Team’s To-Do List

The Scrum Guide defines the product backlog as an “emergent, ordered list of what is needed to improve the product.” But whose list is it?

It’s a mistake for Product Owners or Project Managers to take singular ownership of the product backlog, loading it up with tasks or requirements that the developers must undertake. Becoming overly possessive of the product backlog can turn it into more of a list of static requirements. This runs the risk of alienating stakeholders from interest in the product backlog and engagement with the Agile team.

How To Fix Mistake #1:

In a high-functioning Agile organization, the product backlog is shared between business stakeholders and developers (engineers, designers, analysts, and other creatives building the system). This provides the opportunity to build trust and partnership.

In practice, sharing the product backlog hinges on several key practices:

• Keep the product backlog “business friendly”: product backlog items (PBIs) that are comprehensible to business stakeholders keeps interest high and makes participation in prioritizing possible. User stories, which are short descriptions of functionality from the perspective of the end user, are one way to keep the backlog relevant and readable to your stakeholders. Keeping the PBI title clean and connected to value is another.
• Engage and align stakeholders at the right level of PBI: Most stakeholders don’t care about the next two weeks of the team’s work. What they do care about are about are the higher-order backlog items (e.g. epics) that will drive the business outcomes for which they are responsible. Expose and prioritize higher order work items with your stakeholders.
• Leverage the stakeholder review to build partnership: the stakeholder reviews built into both Scrum and Kanban provide the opportunity to examine work results, solicit feedback, adjust the product backlog, and revise the plan. This vital event is the place to build trust through demos and collaboration towards the desired goals.

Mistake #2: You Confuse Strategic and Tactical Prioritization

Prioritization, a.k.a. ensuring what the developers build delivers value to stakeholders, is central to the role of Product Owner. You need stakeholders to care about, and participate in, prioritization. But doing so at the level of the product backlog itself is a mistake. Stakeholders simply do not care what happens in the sprint’s two-week cycles. They are thinking in business outcomes that are realized over multiple months or quarters.

How to Fix Mistake #2:

The process of aligning stakeholders on the business outcomes is accomplished through creating a variety of collaborative frameworks such as roadmaps, impact maps, and product trees.

Learning and leveraging these artifacts hold the key to engaging stakeholder in strategic prioritization of your product features, fixes, and enhancements.

Mistake #3: You Emphasize Requirements Delivery Over Requirements Discovery

When starting out with what you assume is a reasonably well-known set of desired features and functions for an app or system, it’s tempting to dump the “requirements” into the product backlog and focus on delivering them sprint to sprint. This mistake sees the product backlog as fixed, fails to incorporate feedback or learning, and places the team’s attention on “delivering to plan.” The risk with this approach is over-delivering and missing out ways to shorten time-to-market.

How to Fix Mistake #3:

Fixing this mistake begins with the recognition that the design and development or enhancement of any complex system is a journey of discovery. You must discover the customer’s needs, the solution that will most elegantly meet those needs, and how to build that solution with many changes along the way. An iterative, incremental approach is an approach that respects and embeds discovery in its process model. Identifying and working in increments drives learning, reduces risk, and allows you to deliver valuable working software to customers.

Mistake #4: You See Your Strategy as a Bucket, Not a Filter

Planning cycles that happen away from the product team can result in a large set of work, usually aimed at achieving a strategic objective that is ultimately placed in the team’s product backlog. Deploying strategy that is often divorced from the historical reality of the product is akin to “filling a bucket” with features that must be built and delivered over the subsequent time frame. The risk of this approach is missing out on higher value items (that might emerge as the team learns more about the customer or market) or over-building the system. Saying “yes” to all requested work, as is often expected from the planning meetings, prevents discretionary decision making that ensures the product team is responding to what customers truly need and value.

How to Fix Mistake #4:

With the implementation of a visual decisioning system, your strategy can serve as a powerful and dynamic filter for your product backlog. The filter model invites us first to consider the strategic fit of a customer request or proposed feature. Weighing the request against the strategy enables us to discard the idea should it not align with the strategy chosen and supported by stakeholders. If the PBI passes the strategy filter, it would then be considered in a more tactical way by sizing and scoring the feature based on value or return on the investment needed to build it.