It's a box, in a box, in a box.. It's your product backlog
The concept of Product backlog is a popular aspect of agile software development, specifically with Scrum teams. The Scrum guide talks about two kinds of backlogs: the Product Backlog and the Sprint Backlog.
The Product Backlog contains an ordered list of work that needs to be done to build or improve product capabilities, while the Sprint Backlog constitutes of a short term (Sprint) development plan with selected items from the Product backlog.
While Scrum recognises Product backlog as a “single source” of work undertaken by the team, in practice, many teams find themselves maintaining several sources of work either by choice or unknowingly, that not only undermine the core idea of agility but also sabotage any efforts to bring transparency and concrete improvements in team’s ways of working.
Having worked with numerous teams over the years, I have found certain alarming backlog management anti-patterns that paralyse teams and mark any non-targeted improvement efforts futile.
Listing some common ones below
Excel Backlog: The Roadmap That’s Not on the Map
Organisations tend to have a long-term initiatives with projects spanning a year or more. These initiatives are maintained separately from the Product Backlog and often exist in the form of a typical project plan on an Excel spreadsheet, presentations or a document. They act as a roadmap with predefined timelines, guiding the entire product development process.
Such backlogs are meant to paint a high level picture for leadership, and are maintained by middle management who routinely map the initiative progress based on the ongoing development activities tracked in the team’s Product backlog.
These backlogs are rigid, reek of upfront planning with fixed scope and are totally disconnect from ground reality. Not only do they compromise on adaptability and option thinking, they also dilute the value focus and hurt transparency on organisation’s goals.
Blocked Backlog: The Pileup of Unfinished Business
A list representing collection of items that remain stagnant within the product backlog, unable to progress through the Software Development Life Cycle (SDLC). These items can include unresolved issues, dependencies, or challenges that prevent them from moving forward.
Even when not in form of a formal backlog, such items are often grouped and represented by a status in tracking tool or a custom filter, creating a backlog of its own. A Blocked backlog can obstruct team’s progress, as unresolved issues can lead to inefficiency and create bottlenecks in the development process. A growing list of partially done work also threatens to destabilise the system and hurts the flow.
The presence of these backlogs can be linked to team structures and planning methods. Teams focused on specific technical stacks or components may experience more Blocked items, while product-focused teams tend to have fewer. Additionally, isolated planning among component teams within a larger system can lead to inter-team blockages. Collaboration and system thinking with global goals are vital in preventing these bottlenecks.
UAT Backlog: The Wait That Never Ends
User Acceptance Testing (UAT) is a crucial activity in the development process. However, sometimes items get stuck in UAT for an extended period, often due to communication gaps, partially done work with lack of understanding, or development work with no independent value quotient until integrated with others (e.g. Front-end only, Back-end only, API only work)
Items stuck in UAT can delay releases and disrupt the rhythm of sprints, making it challenging to meet customer expectations. Such items are often carried forward through multiple sprints untested, accumulated until an integrated releasable version is ready for testing.
This could be an indicator of various issues, like team’s ability to deliver end to end feature, weak or missing definition of done, or the inability to break down work in valuable chunks that can be validated and delivered continuously.
Migration Backlog: Long Pause Before Play
Sometimes teams pick migration activities like transitioning from an old technology platform or tech stack to a new one, or paying back technical debt as a project of its own. These initiatives can be extensive and may span multiple sprints or even months.
Migration Backlogs divert team’s attention and capacity from the core value delivery work, to prolonged period of housekeeping activities, which should have been either a periodic assessment of system “illities” or a regular hygiene to ensure quality at all times.
Quality as an after-thought, and system hygiene as a ceremonial activity once a year or more is both bad for software design and risk for business agility.
By acknowledging and proactively addressing such backlog anti-patterns, teams can make meaningful impact to enhance their agility and maintain a sharper focus on delivering value to their customers.