Warehouse analogy for managing a backlog
It turns out warehouses and backlogs have a lot in common
I worked in countless warehouses growing up and really enjoyed it. I liked the organization they had, the physicality of moving stuff around, driving pump trucks around with pals. I never thought all that would come in handy as a product manager years later, but it turns out warehouses and backlogs have a lot in common.
Backlogs are tough to manage and an out of control backlog is a huge drain on the team: work gets lost, time’s wasted combing through it, everyone's anxious they’re not working on the right thing, and morale drops as you never feel like you’re making progress.
How familiar do these backlog experiences sound to you?
Our backlog has more than 100 tickets
Half these tickets are more than 6 months old and created by people who don’t even work here anymore
Constant re-reading and re-prioritizing the same tickets week after week
The feeling there’s something in there you forgot to do
People creating multiple tickets for the same things because there are too many tickets to know what’s in there
No matter what you do it seems to keep growing
Over the years I’ve tried all the recommended practices for managing a backlog but none of them worked for me. They all broke down when things got busy. The problem was they depended on perfect process and constant attention. It was like having a fine-tuned race car engine – if one thing breaks the whole thing explodes. So best practices make sense in theory (“everything should be in priority order and you take from the top”) but break down in practice (“who added this ticket at the top of the backlog?”).
In a constantly changing and unpredictable environment (i.e building software), you want robustness, not raw performance. You don’t want Formula 1, you want grease-fueled diesel truck.
The warehouse analogy
Robust systems usually are built on simple rules rather than precise processes, with people filling in the gaps. When it comes to backlogs, a warehouse is a perfect analogy to illustrate a simple set of these rules. By using these rules and letting your team naturally develop their own ways to fill in the gaps, managing a backlog becomes easier and coordination costs (meetings) go down. (If you haven’t worked in a warehouse, don’t worry, this is all very intuitive.)
Three important characteristics of a well-run warehouse:
There’s a managed flow of things in and out
Only relevant things are on the shelves
Everything has it’s place
These are exactly the same characteristics of a good backlog! Here are those above three characteristics using backlog terminology:
There are clear channels where tickets come in, and a way for old tickets leave and be archived
It contains only work that will be done (no future ideas, wish we coulds, or shoulds)
Every ticket has been categorized, and every category has a clear plan of action
Let’s talk in more detail about each of those.
A flow of things in and out
In warehouses, the products come in from different suppliers. Those products are stocked on the warehouse’s shelves. On the other side, customers order things. Those products are picked from the shelves, boxed, and shipped out. That’s the primary flow, but there’s also another one that deals with products that no one buys. Those products (which are no longer relevant, out of season, no longer for sale, etc.) are sent to clearance centres, freeing up space on the shelves for new things.
In backlogs, tickets come in (from support, QA, logged internally), and leave the backlog as releases to users. But there’s rarely a mechanism for removing tickets that are “ out of season” (no longer relevant). This is a critical step — without this your backlog will grow indefinitely.
I’ve found a time-based mechanism is the best for removing things. It’s like when you bookmark an article to read and a month later you haven’t, or put a movie in your watchlist but six months later it’s still there; you like the idea of reading or watching it, but time has made it clear it’s not that important. Same can be applied to backlog tickets.
This will initially cause some contentious conversations because it’ll feel like you’re actively neglecting the product. But the truth is that whether you acknowledge it or not, there’s no way to fix every bug in your app and build new functionality – there’s not enough time or people. At least this way, it forces the conversation about what’s important rather than just putting it in the backlog and saying “we’ll get around to it.”
Contain only work that will be done
If you had a personal to-do list of all the things you needed to do in the next year, it would be pretty difficult to find and focus on what you needed to do today. That’s what most backlogs end up being – they become a to-do, should-do, could-do, would-like-to-do, wouldn’t-it-be-cool-if-we-did list – and it makes getting work done more difficult on any given day.
The backlog should contain only the work that you definitely plan on doing in the foreseeable future. New feature ideas, big refactoring projects, small edge case bugs should be kept somewhere else, only coming into the backlog when you intend to work on them.
What you see is what needs to get done.
This helps everyone stay focused and gives you peace of mind that nothing will fall through the cracks.
Everything in it’s place
In a good warehouse, every product has a specific place on a shelf. That’s because wandering around looking for something is a waste of time. And if you don’t know where something should be it’s easy to lose track of it. The same should be true of backlogs. No developer or product manager should “wander around the backlog” trying to figure out what to do next or what tickets are important.
Just like every item that comes into a warehouse is tagged and given a place on a shelf, every ticket in a backlog should be categorized. Each category should then have a specific plan of action. These are the categories and actions I like.
Features – Projects with a defined beginning/end (traditionally an ‘epic’ in Jira)
Foundations – Ongoing work on code quality and tools
Fixes – Bugs that we plan on fixing
Fixes [for archive] — Bugs that are about to expire and be archived (so you have one more chance to decide how important something is)
Fixes [next release] – Bugs blocking the next release (i.e. high-priority)
With the requirement that every ticket has a category, new tickets are easy to spot because they don’t have a category.
Keeping a backlog in order will always take work, but these basic rules will help keep it under control and organized in a way that makes it feel like it’s helping your work, not causing more.
Video
More details about how tickets flow through a backlog in this video.