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 […]
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.
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.
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:
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.
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.
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.
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.
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.
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.
The purpose filter supports more dynamic decision-making and increases your team’s Agility by enabling more responsiveness to customer needs and market opportunities.
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.
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.
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.
Scrum is a framework that operates in a rhythmic cadence called “sprints,” which are fixed...
In Scrum, all the items in the product backlog are called product backlog items (PBIs)....
If anyone has ever been in a painful sprint planning meeting, one of the things...