Your backlog is a prioritized list of features, bugs, technical work, and knowledge acquisition needed to meet the desired functionality of your product the product. It is one of the essential artifacts used by teams that adopted an agile product development methodology such as Kanban, or Scrum.
What Is Backlog Management?
Backlog management is the continuous process by which the product owner, in collaboration with other stakeholders, will add, remove, adjust, groom, and prioritizes the items listed in the backlog to maximize the chances that every “next shippable increment” of product released brings the greatest value to users/customers.
An oversized (and “unmanaged”) product backlog impedes innovation and becomes a problem by slowing down time to market and causing frustration, even in the best product teams. if it grows uncontrollably, the value it provides diminishes.
The Challenges of Backlog Management
An unreasonably long backlog is a major pain point for many product teams. Under the sheer amount of information, it becomes unmanageable, irrelevant and might as well be abandoned.
A poorly managed, and large backlog causes many problems:
Maintenance costs: Long “queues” incur cost because every item requires a little attention to remain valid. Grooming a fat backlog seems like an insurmountable task and is often omitted. Soon enough, the entire backlog becomes obsolete.
Value reduction: When tens or hundreds of items are competing in a backlog, each item seems less significant. We have a hyper choice of possibilities, which reduces the likelihood to choose best what to do next. When backlogs get too big, they become a trash bin where all the work you want to do, but never will, ends up.
Inhibited innovation: Reorganizing a big backlog is such a chore, that “brilliant” ideas, or simply the “latest” ones, are either added at the front of the end of the backlog, not to be lost. Adding items to the front invalidates the rest of the backlog while adding them to the end guarantees they won’t be done.
Why Your Backlogs Get Too Big?
With these problems in mind, let’s look at how backlogs become oversized. Truth is, there is not a single cause. It is often a combination of factors.
Hoarding: People are hoarders by nature. They have a hard time throwing things away. “Good ideas” are even harder to throw away. Stop thinking about what should go in your backlog, and start deciding what should go out.
Information needs: As responding to change is an important part of agile development, the further in the future we have detailed our plans the less certain they become. The information granularity in the backlog needs to reflect that. a good backlog should be detailed appropriately, not excessively.
Dependency resolution: When a team is not truly Agile, they strive toward resolving dependencies far into the future. To identify dependency chains, they break down large items into their components and reduction goals into tasks. Not only it inflates the backlog, but it also means the backlog is no longer value-driven in the short term. Instead, it heavily focuses on tasks to do.
No committed product owner: The product owner’s responsibility is something that shouldn’t be taken lightly. Many organizations developing software products have too few product owners in comparison to team size. Therefore, the time they have to manage the backlogs is minimal and insufficient.
How to Make the Backlog Lean
Below are a few suggestions to “heal” your backlog:
Product Ownership: There should be one person assuming the role of “product owner” who is responsible for the backlog of every agile team. Preferably, she is only responsible for the backlog of her team because she needs to have enough time available for maintaining her backlog in collaboration with her team and stakeholders. She needs to be(come) knowledgeable about the product and have the authority to make decisions within the backlog without the involvement of other parties.
Limit Amount of Future Work: Consider the number of items in the backlog to ensure that our pipeline isn’t planned for years and years as this could seriously inhibit innovation. However, it’s hard to give a piece of general advice on how long a roadmap should be as it depends on a lot of factors, such as product type and market maturity.
Limit Partially Finished Items: “Design-in-Process”, also known as “DIP”, the “IT” analogy to “WIP” for “Work-in-progress”, used in manufacturing describes the partially finished work. Incomplete work is a waste in the IT industry, though it’s not as visible as in the manufacturing industry. A good starting point would be to set a limit as to how many partially finished items you can have in the backlog at one time. There is not a size that fits all, but keep in mind that since a PO is mainly responsible for one backlog, her capacity to administer the information is the limitation.
Decide How to Manage the Backlog: Even though it’s the responsibility of the product owner to maintain the backlog, she is not the only one that should contribute to the vision. With a simple and clear strategy of how to manage the backlog and involve the team in that process, everyone on the team should be able to contribute, continuously, to the process of keeping the backlog fresh. For this to work, everyone needs to understand that the backlog is an essential component for the health of the product, its vision, and its roadmap.
No Cheap Seats in Your Backlog: Restrain yourself from entering every idea that comes up. Keep them for a while in your head, if they are still there after a week it might be worth adding to the backlog. In association with that, it’s essential to apply a soft “one in, one out” policy as you are hitting the limit of design-in-process items you have set for yourself. Discard potentially good ideas is never easy, but this is a trait of good product ownership.
Work With an Aging Idea Funnel A product backlog can be divided into several stages where the design-in-process limit could be more difficult the closer they are to implementation. A simple approach is to allocate the most left portion of the backlog to “new ideas”, and another portion or the right, which is more thoroughly groomed and restricted in size. To avoid flooding with “new ideas”, give items an age limit, or due date, so that the ones that are not being prioritized will expire and can be removed over time. When the idea is moved to the right, it indicates a commitment from the PO that this idea will be implemented eventually.
Bringing It All Together
Hopefully, this will help you take your product backlog from being an unmanageable, fat colossus to a lean roadmap helping you accelerate innovation and deliver the best possible product.