5 Mistakes You Must Fix to Master Your Product Backlog

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.

Purpose-Filter

The purpose filter supports more dynamic decision-making and increases your team’s Agility by enabling more responsiveness to customer needs and market opportunities.

Mistake #5: You Over-Invest in Up-Front Requirements Analysis

Engineers crave information and certainty, and engineers building software are no different. In Scrum, we use the activity called refinement to break down and further define product backlog items. In Kanban, we call this same process “discovery.” With engineers in a room, ask them to provide an estimate on the size or effort required to complete the item. Then, open the floor for questions. You can quickly fall into a “rabbit hole” of questions and fringe cases out of which you may never emerge. This tendency to seek full and comprehensive understanding of a PBI in refinement is a trap I see many teams fall into.

How to Fix Mistake #5:

In the below diagram, Scrum practitioner Giora Morin challenges us to consider where we are investing our time in adding detail to PBIs. Option A depicts heavy up-front analysis in the refinement session while option B depicts a “just enough” analysis approach that readies PBIs for the planning session.

Crafting an explicit team agreement for what it means to be “ready” for sprint planning can be a step in the right direction. But proceed with caution; we want the “ready” criteria to be a guideline that informs us when enough analysis has been done, rather than a phase-gate for a PBI to enter sprint planning.

product backlog refinment

Agile teams and the people that comprise them learn fastest and best by doing the work as opposed to talking about it. The Scrum Guide’s rule of thumb for product backlog refinement is no more than 10% of team capacity. Respecting this time allowance and keeping refinement of a given PBI to its own time-box (e.g. 15-20 minutes of discussion to reach consensus on a size for the item) are two healthy steps to combat this mistakes.