The product, or team-level, backlog serves many purposes and is the single most important artifact for Agile teams. It essentially serves as a development team’s to-do list, based on end user’s needs, their experience, and desired business outcomes. Any and all work a team executes on is managed through their backlog and, as a recent McKinsey article points out, a refined backlog can even help teams navigate change, like abrupt transitions in and out of the workplace.
On the other end of the spectrum, when organizations get the product backlog wrong it inherently adds complexity and risk, which are contrary to overall agility. In short:
- A neglected backlog obscures the most important and valuable work to be done, causing confusion among the team.
- An ignored backlog misses some of the work that the team executes on without visibility outside the team, slowing delivery of high priority features and capabilities.
- An unhealthy backlog makes communication challenging and can result in delivery of the wrong outcome.
Never fear. You can tame your backlog, and Polaris can help. In this new series, we’ll look at three considerations–ownership, contents, and prioritization–that are central to demystifying and reclaiming your team’s to-do list. In this first post, we’ll dive into common issues of ownership along with a few other characteristics of unhealthy backlogs.
Top Anti-Patterns of Backlog Ownership
The Product Owner title is extremely intentional. The most important artifact for an Agile team requires clear ownership and, without it, excessive risk and waste await your team. The best-case scenario for backlog ownership is a single, dedicated Product Owner who works with a single Agile team. Another acceptable scenario is a single Product Owner who is part of two teams, time allowing. Beyond these two acceptable scenarios, you step into the territory of anti-patterns of backlog ownership. The most common of these are:
- Multiple Product Owners for a Single Team – This scenario creates competing priorities within the team itself, potentially causing internal discord, and certainly splitting focus and increasing time spent on context switching.
- Product Owner by Committee – In the committee model, priorities are debated and agreed to by a small group–usually the Product Manager, Engineering Lead, and a Business Lead. This approach seems manageable, but it begins to break down when it’s time to write and refine stories. That’s assuming the group even agrees on prioritization.
- No Product Owner – This scenario creates the most chaos and waste. Team members must use considerable time understanding work requests and confirming priority. It also opens the door to the team having to capture new work requests directly from stakeholders.
The value of a true, single Product Owner is underestimated too often. Your Product Owner is the person who is accountable for synthesizing customer needs and business requests into valuable, actionable stories within your backlog. It is already not an easy job. The anti-patterns above will quickly cause a workflow to break down at the most critical point–when your team must commit to completing the work.
Without a single decision-maker to guide them and own the backlog, teams spend critical time filling the gaps. Competing priorities put pressure on them to negotiate directly with stakeholders, which can lead a team to commit to too much work. Unclear stories and acceptance criteria require the team to gather or assume context, resulting in delays or delivery of the wrong outcome.
Organizational respect for the Product Owner and their decisions is a must for success. Shared responsibility for the backlog by the team is a positive sign of a collaborative and healthy team. That said, the Product Owner remains accountable for backlog management, whether certain tasks are delegated or not. When fully empowered and trusted with decisions regarding priority and the user experience, a Product Owner will maximize the value a team can deliver and drive the outcomes your business depends on.
More Characteristics of an Unhealthy Backlog
Product backlogs are not well-kept for a wide variety of reasons that extend beyond unclear ownership. Defects may be automatically added to a product backlog through error handling processes. The product backlog might be made accessible to anyone in a company with the ability to add whatever items they want. Backlog items lack appropriate detail and acceptance criteria in general.
When these dynamics are present, it’s too easy for the backlog to become a ‘junk drawer’ or ‘cluttered closet’ filled with every possible thing a team should consider working on. You’ll know this has happened when your product backlog:
- Feels too big. Years’ worth of items that are low priority clog the backlog making it difficult to find items at times.
- Lacks epics and features. Without a clean hierarchy of items, dependencies can remain hidden until emerging once work on the item begins in earnest.
- Gets too technical. This means there has been a loss of focus on the end user and their experience.
- Is not prioritized effectively. If a team member finishes a story and goes to the backlog for their next story, are you confident that they would select the highest priority item?
- Is not sized or estimated appropriately. This manifests in new teams naturally and in larger initiatives that span more than a calendar quarter.
If any of these characteristics remind you of a particular backlog, it likely needs some attention and refinement. Luckily, Polaris offers a two-hour working session wherein our Agile experts will review your backlogs and discuss opportunities to improve the value they provide to your team and organization. Reach out today to get started. And stay tuned for upcoming posts in our Taming the Backlog series, where we’ll dive into what contents and prioritization look like in the healthiest product backlogs.
Back to Blog