Ep10: TL;DR: Backlogs

TheBurnUp Podcast - Tl;Dr Episode

Most software delivery use a story backlog to manage delivery: effectively a list of things to delivery. But often the backlog is at best a mess, at worst confusing and misleading.

A good backlog provides structure and facilitates delivery, a bad one adds confusion and inefficiencies.

Here is our 5 minute fix to help you optimise your backlog.

Show Notes

THE KEY IS THIS: use the Story Backlog in the right way:

ONLY Use it to drive delivery

Don’t use it for strategic purposes.

The reason is this: A backlog is effectively a ranked list. This makes it good to manage work, butbad when the bigger picture and wider context is required. For such strategic purposes we have better tools at our disposal: use  roadmaps, experience or storymaps or requirements hierarchy to make strategic, value proposition or capability level decision.

Once you have understood what your backlog is used for, fix your backlog:

  • Keep it small AND apply lean principles
    • Reduce noise by not flooding it with items that you may work on in the far future
    • Reduce waste by only focusing on the items required in the near to mid-term

If your backlog has thousands of detailed items that you may or may not work on in the future it is too big. Get rid of the noise, use roadmaps and storymaps to do such future planning.

  • Only add quality items
    (value, user centric, evenly sized, at the right level)
    You may want to consider a ‘dumping ground’ where stakeholders can ‘add items’ (to not forget them) but you will want a structured process on how these get reviewed and added to the backlog proper
  • Keep it well structured
    Stories of similar size and similar level
    Group stories into epics and features that make contextually sense.
    While your backlog is a ranked stack (used for delivery) it’s underlying requirements structure is a tree that decomposes a value proposition into themes, features, epcis and stories.
  • Make it understandable
    A stakholder should be able to make sense of the backlog without much context or explanation
  • Make it clean, and keep it clean.
    Frequently review the backlog. Add new items in a controlled way, ensure their quality, remove items no longer needed, adjust priorties.

Warning signs for a bad backlog are:

  • Backlog reviews take hours or days
  • Thousands of prospective items
  • Detailed items that may be worked on in the far future
  • Items cannot be understood by just reading them
  • Items are grouped not by functionality by other categories: for instance, do not allow epics such as ‘‘Items to be done next week’. While the backlog is to drive delivery via its ranked order, the underlying hierarchy of themes epics stories must be feature and functionality focused. Otherwise you loose context and user centricity.

Further interesting reading:

The Digital Business Analyst blog: Clean up your act: User Story and Backlog Best Practices

The Digital Business Analyst blog: Is Backlog a Dirty Word?

The Digital Business Analyst blog: What makes Good User Stories

The Digital Business Analyst blog: Why we should Visualise Requirements

The Digital Business Analyst blog: Storymapping – a Guide

Adaptive Path: Anatomy of an Experience Map



Leave a Comment