If a customer submits a request for a cool idea, maybe we don’t have time to do it now, but a good idea is a good idea - we should just stick it in the backlog right?
Of all the concepts in the current Product Flow, the backlog is the most harmful. Backlogs are full of promises that can’t be kept, ideas that will never ship, and problems that endlessly fester. And they accomplish all of that while draining your team’s time and energy.
There is a real problem to solve here. As we discussed in Queue Theory, we know that work will flow into the team regularly, and we have to decide how we are going to triage and manage that work. But backlogs are the worst solution to a real problem.
Stories are inventory, and inventory is expensive. Here are some of the ways that backlogs cost you money.
Grooming a backlog of 8 stories takes far less time than grooming a backlog of 100 stories.
When triaging a request or a bug report, is this a duplicate? You have to scroll through hundreds of old stories to find the duplicates
Are you going to put some effort into validating or shaping the story before it ends up in the backlog? How much time are you spending shaping work that will never ship? If not, when you look in the backlog how do you remember the context of the request?
Backlog costs grow exponentially
The biggest problem is that a long list is more expensive to maintain than a short one - and accepting more work into your backlog than you can possibly complete creates an endlessly growing list. The typical Cumulative Flow Diagram for a company that puts things in the backlog looks like this.
The backlog is endlessly growing, and over months quickly shifts from a manageable 10-20 items to hundreds of stories. This sheer weight of noise drowns out real work that is important and useful.
At what point is the backlog so large that you can no longer scroll through it, but instead just turn it into a searchable database of half-baked ideas?
When a customer has a request that is very important to them, they will often press for some indication of if/when it will be done. It’s easy to grab their request and drop it into the backlog somewhere - maybe you have decided that its 10th in the queue and can communicate that to the customer.
But while you are working on shipping the top 5 items in the queue, more requests will come in - some of them will become more urgent than the request you placed 10th. So you drop them higher in the queue. Soon that item which was 10th in the queue is now 15th, or 25th.
A key principle of Queue Theory is that your service rate (the rate at which you ship work) MUST be greater than your arrival rate (the rate at which new work enters the queue). If you violate this principle then the queue will end up jammed and unproductive.
Backlogs create the illusion of order, but actually create disorder.
Why are backlogs fundamentally bad?
There is a great maxim called Lindy’s Law which states that the likelihood of something sticking around is directly proportional to how long it has already stuck around. There are lots of examples of the Lindy Law all around us.
The average book is in print for only 1-2 years, but a book that has been in print for 40 years is likely to stay in print for another 40 years.
Friendships come and go as people age, but someone who has been a friend for 10 years is likely to remain close to you for another decade
Most performers may only end up in 1-2 films, but if an actor has starred in 20 films they are likely to star in another 20.
The general thesis is based on the observation that there is a filtering effect in place, and the longer something goes without ending, the more filters it has passed and the more likely it will continue to pass future filters.
A book ends its run when it fades from popularity, but a book that has stayed popular enough to run for 5 years has proven that it has some staying power - making another 5 years likely. A book that has stayed in print for 100 years has greatly proven it’s lasting appeal and it very unlikely to fade from print for another hundred years.
Backlogs have the same mechanisms, although in reverse. For a backlog the filter is “it’s important enough to prioritize and thus ship.” The longer a story stays in the backlog (the longer it’s not important enough to actually prioritize) the more likely that it will never become important enough to prioritize.
Here are a few techniques to manage a backlog effectively.
No Backlog
The best way to manage the backlog it to prevent anything from getting in to it to begin with. A simple way to accomplish this is with Now/Next/Never. In this model, when you are triaging incoming stories (requests and bug reports) on a daily basis, you quickly sort them into one of three buckets:
Now - this is reserved for work so time critical that you want devs to stop what they are doing at this moment and focus on this issue. This bucket commonly includes outage-inducing bugs.
Next - this bucket is for all work that is important enough to prioritize over the current queue, but doesn’t need to interrupt work-in-progress. This bucket often includes all bugs (especially in zero bug cultures), as well as extremely high value features
Never - Everything else goes into this bucket and is archived. Even if the idea is a very good one, you close the story and move on. This should be almost every item that isn’t a bug.
This approach prevents a backlog from growing at all - and keeps focus on things that are actually shipping.
Age limit the backlog
In some cultures, the idea of getting rid of a backlog is too extreme, in which case there are some options for how to manage a backlog more effectively.
By Age Limiting, you agree that if something hasn’t been done in a certain amount of time (say 14 days, or 30 days) that you will automatically close it or archive it. This approach essentially applies the Lindy Effect directly to the backlog and realizes that old stories won’t ship, and so we prune them out after their expiration.
A trade-off is that this does permit a backlog to grow to an indeterminate length, capped only by the arrival rate of new stories into triage. As the volume of requests coming in grows, so will the age-limited backlog.
Cap the size of the backlog
In this model you set a WIP limit (work-in-progress) on the backlog, capped at, say, 10 items. Whenever a new story comes into the backlog, you either have to drop it - or if you want to keep it in the backlog then you have to drop the 10th story.
This approach permits a bit more prioritization and keeping a queue of visible stories, and old idea that stays in the top 3 in the backlog continues to stay there, at the expense of new (but less valuable) requests.
The trade-off is that constant prioritization and ranking of items can be a costly exercise, with lots of time spent trying to optimize the existing backlog.
But what about…
There are many common objections to eliminating, or capping the backlog, none of them good.
But it’s a great idea!
If it’s that great idea, why aren’t you doing it now? And besides, if it is that great of an idea, then it’s going to come up again, and again and again.
One of the biggest wastes in backlogs is duplication, but we can lever it into a strength. Because the best ideas keep coming around, we can rely on that principle to ensure that the really great ideas will re-enter our queue again in the future and give us multiple chances to prioritize them.
But I don’t want to lose this context!
In modern product management systems, nothing is ever lost. A story that is archived or closed will be searchable long into the future - you can always go back and find it later if you decide that you need to.
But I’m really, really serious about doing this next month
Backlogs are very similar to diets or gym memberships - often made with the best of future intentions. If it’s important, then do it now. But if you won’t do something now, why do you think that Future You is going to see this work as even more important than Today You? Especially as Future You is only going to be more busy and have even more incoming requests to sort through.
Meaning to do something later is a comfortable lie - it makes us feel better about not prioritizing something now, even though we know that we are very unlikely to see the same thing as more important later.
