Why Your Backlog Might by Rotting
By Austin Aldrich
My name is Austin Aldrich and I’m a Lead Software Developer at unosquare with a ton of experience in both backend and frontend development. Over the years, I’ve had the opportunity to manage complex projects and witness firsthand how ‘rotting’ backlogs can become major obstacles; on the flipside, I’ve seen how a few simple changes in approach can give operations a much-needed facelift. So begins the inspiration for this two-part series…
One of my favorite podcast episodes ever made is a cautionary tale about the Sultan of Brunei’s bizarre obsession with collecting cars. As documented by Michael Sheehan, the oil-rich ruler owns an uncountable but estimated at 7,000 vehicles. His numerous garages include 400 Bentleys, 600 Rolls Royces, 200 BMWs, and 200 Ferraris. He even keeps a Rolls Royce running in front of his palace at all times. The whole story is fascinating, if not sad and, frankly, irritating. According to Michael, the air conditioning in several of the buildings was not functioning. In the tropical climate of Brunei, that’s disastrous for the health of the cars. To add insult to injury, many of the vehicles had not been started in five years. This means a sizeable chunk of his collection is slowly rotting.
That’s a sad story, but I promised a cautionary tale, and it’s this: your backlog is a rotting parking garage of tickets. Some of them you likely haven’t looked at in five years. I can almost guarantee you there are numerous outdated or duplicated entries that are doing no one any good. Traditional solutions like backlog refinement are often wishful thinking – falsely promising us that one day we might get our backlog into some semblance of a usable state. Radical solutions like eliminating the backlog altogether might not be feasible if your team is tethered to something like a Scrum-based workflow where it’s intrinsic to the process and is how your project management team has been trained to work.
Instead of giving you a “hot take” where I suggest the absolute answer of whether you should keep or ditch your backlog, I want to offer some helpful insights that I’ve learned from years of software development as well as some advice I gleaned from Basecamp and Lucas Costa. I don’t agree with their conclusion that eliminating a backlog altogether always makes sense (especially if you work in a consulting agency like we do here at unosquare). Still, I’ve done my best in this article to capture the spirit of their observations and apply them in a reasonable manner to help teams work more efficiently without radically altering their existing workflows.
Why Do Backlogs Exist?
First thing’s first, though. Why do backlogs exist at all? Simply put, they are a place to store future work that will be groomed and put into a later sprint. The idea likely evolved somewhere in the evolution of the Scrum framework in the mid-1990’s.[1] According to the Agile Alliance, it’s defined as “a list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome.”[2] So, it’s a place of “might be’s” As your project matures, those ideas and bugs will continue to pile up. The traditional Scrum answer to this is that you should use backlog refinement sessions to clean out things that are no longer relevant.[3] And I agree, this does work for items near the top of the queue. But fast forward a year or two. Add several customers, a couple of project managers, developers, QA engineers, and support staff. Now the influx of items will certainly outpace the team’s ability to maintain them over time. You’ll never get to the bottom of your backlog.
You might be saying, “So what? Of course they will grow. That’s why we have search features in our ticketing system.” But I want to challenge the assertion that boundless space is truly free and harmless so long as you can fish out what you need. That is the philosophy that allowed the Sultan’s car collection to become so unwieldy. Unfortunately, unbounded backlogs come with some drawbacks that are not good for your team or your customers.
The Problems of a Bottomless Backlog
Dampened Team Morale
The first negative effect of large backlogs is that it dampens the team’s morale. Like it or not, we productivity workers have been trained to treat any kind of list as something that must be completed. And we are taught by agile methodologies like Scrum that an item should be picked from the backlog and moved methodically into a development cycle until it’s done. But what does that imply about all the other items that don’t get picked? That they will never be done! And that’s not a good feeling when a considerable number of those items are bugs. “Our software just keeps getting more and more bugs…will we ever make a dent in these?”
Misleading Metrics
Secondly, bottomless backlogs tell a deceiving story. If you are unfortunate enough to work in an organization that weaponizes agile metrics to gauge performance, you may find them unfairly examining the product backlog to identify defect ratios, the team’s velocity on feature development, or any number of flawed statistical strategies that end up making teams feel and function worse than if they’d had no backlog at all.
Atrophy
The third problem is atrophy. Remember how the Sultan’s cars fell into disrepair because he didn’t perform periodic maintenance? The same will happen to your backlog items if you just record an idea, bug, or feature request then abandon the ticket. It will be compressed down like a fossilized layer from the weight of decisions made after it. I can’t tell you how many bug tickets we pull out of the backlog that were either fixed long ago in another release or we can’t even remember what exactly the problem was, so we just delete the ticket. It can be tempting to think, “I just want to capture this so we can come back to it in the future.” That sounds nice–the responsible, organized thing to do. I get it! But by the time the future comes, your context window will have changed. Features that made sense when you had 10 customers, and your product was focused on market segment X are irrelevant when you have 500 customers and are focused on market segment Y.
Now What?
By now, you’ve probably recognized some of these issues in your team’s backlog, so what’s the solution? In the second part of this series, we’ll explore practical strategies for managing bugs, using alternative tools, and scheduling releases to de-rot your backlog.
Stay tuned for Part 2.
