Your team’s backlog is a fridge. Clean it out!
Take a look in your fridge. It probably looks pretty familiar, and a little cluttered. It might be hard to find certain things. In many ways, this is similar to the backlog for your software team. And while useful, both might be a little stinky.
And you could probably categorize their contents in similar ways, too.
FRESH & READY TO EAT
Of course you eat all this first, especially if it’s already prepared. It’s why grocery day is the best time to snack. There are too many choices!
In a software project, these are the normal stories you pick up and the bugs introduced by recent changes. You know all that code well, so you pick them up and complete them efficiently.
In terms of the fridge, a few days after shopping, you’re wondering what you possibly spent $200 on at Whole Foods because there’s nothing to eat.
But, of course there’s not really nothing to eat, is there? There’s a whole lot there consuming precious fridge space. Let’s continue to categorize.
FOOD NO ONE WANTS TO EAT
In your life, this is an aspirational purchase that is probably healthy or novel. Say, drinking vinegar or a superfood smoothie mix that sort of tastes like dirt.
In your software project, this is a thankless task that touches parts of the system no one knows about. It’s got “Rat Hole” written all over it. Maybe you’re not even convinced it’s worth doing but didn’t want to rock the boat during sprint planning to challenge it. So of course you pick up that simple bug or fun new UI story instead. And everyone else skips over it as well so all the other work is taken on until it’s left all alone in the unassigned lane.
FANCY INGREDIENTS
You saw a recipe for a photogenic dish on Pinterest and told yourself, “I’m gonna make this!” So you buy all of the ingredients, including some type of chard you never knew existed. The day comes to make it, but it’s been a long day at work. So you give in to temptation and order something oily off Postmates instead. And so the ingredients sit there for while, and you’re still convinced that tomorrow for sure going to make it.
Eventually, if the ingredients are perishable, you’ll toss them and feel guilty for wasting food and money. However, what if you bought a container of something with a really long shelf-life, like miso? That goes right to the back of the fridge. You’ll probably find it when you’re moving out of the apartment.
In a software context, these tend to be the big “we need to rewrite submodule X” or “add tests to Y”-type tasks. They usually come from someone on support who spends hours wading through a mess of code and eventually patches it to fix an immediate issue, but then realizes that if the team just rewrote this messy module (or replaced it with a lib or some other sweeping change) then a future dev wouldn’t be forced to go through what she just went through. So she files a task to do that. And then rolls off support and forgets about it completely. And then when another support person does the same thing for an issue with that code, if they’re lucky they’ll find her original task and +1 it or something and then go merrily along. Or, more likely, since the backlog is immense, after coming up empty after a cursory search, file an essentially duplicate ticket and pat themselves on the back as well.
Don’t be fooled. Think of when you’ve successfully carried out a big refactoring or rewrite? Did it come about from someone perusing the backlog? If so, what made it stand out from all the other similar tasks recorded with good intentions?
In my experience, any significant refactoring only happens opportunistically, as part of some planned roadmap item. It’s an easier sell this way.
“We’re about to add a big feature to Module X. The way it’s written, it will take forever and introduce tons of regressions. Let’s do the right thing and refactor first so we can implement the new feature in a sustainable way.” This is a rational decision, one that a PM would get behind. But if Module X works and is not impeding any present work, even if it’s total spaghetti, then why work on it? No reason. And you never will.
LEFTOVERS
In your fridge right now, there’s probably some dried-up rice in a takeout container. Ditto that last bite of your sandwich from four days ago. In your backlog, this kind of stuff is your story-specific tech debt.
It’s all those TODOs you left in the code. They are often just a subcategory of good intentions, to make yourself feel better about your imperfect (aka shippable, on-time) implementation. However, it’s worth noting here that while there was barely any chance you were ever going to make that soup or rewrite module X, there actually is a chance you’ll eat your leftovers or finish some of those TODOs. However, like real food, the likelihood of success is greatest immediately after it goes in the fridge and plummets thereafter.
In the software context, this is why a transient medium like a sticky note is much better place for capturing these tasks. While you’re waiting for the build, or QA to check out your work, you just might cross a few TODOs off. If so, give yourself a real pat on the back.
But be sure to toss that sticky at the end of the day (or week if you’re optimistic). Don’t litter the backlog or the code with TODO comments under the misguided belief that those will somehow make you complete them.
What experience in your life leads you to believe Future You will be any less busy than Today You?
My own experience has also taught me that Future Me will take far longer to finish any of the TODOs than Today Me, due to lost context, and will even be less likely to bother trying in the first place.
WHAT CAN WE DO?
In some ways, a software team’s backlog is infinitely more annoying to manage than a fridge.
- Fridges can only be so big. Digital backlog tools are essentially limitless, which is another word for bottomless. Like a pit.
- Spoiled food will stink up the whole works. But tech tasks that reference issues that no longer apply look the same at a glance than ones you created yesterday. Any Good Intention task that references the outside world will become dated incredibly fast.
But, just like a real fridge, here are some practices that may help:
- Be ruthless about what you add. Does this sound like a recipe you’ll never make or something simple that you would make on a weeknight? Only capture work that you feel is worth doing and you will have time to do in the near future. Stack rank it against other items in the backlog. If it belongs toward the bottom, it should probably be removed.
- Get a smaller fridge. This will force you to be more selective. Gradually ratchet down the size of your backlog. To add something new, challenge yourself to throw something out. It’s a great way to actually retain important tasks while avoiding the waste associated with keeping around stuff that you’ll never do.
- Write expiration dates on everything. On several backlogs I’ve managed, we had short term parking and other sections that had finite lifespans. The current version of JIRA shows little red dots on tickets as they age which is a nice visual indicator that you’re either neglecting important work or this work wasn’t so important after all.
- Piggyback on planned work. Just like it’s useful to have a “kitchen sink” recipe that easily lets you use up fragments of random veggies in your fridge without having them end up in the compost, purposefully look for opportunities to attach backlog items to upcoming high-priority work streams. It’s a good time to practice your “selling to management” skills.
- Clean it out frequently. If you can’t quickly find what you’re looking for in it, chances are it’s already too big. Give the team an ultimatum. Has it already survived three cleanings? It’s time to pick it up once and for all or trash it. You’ll quickly learn the kinds of tasks that never get picked up and stop adding them in the first place.
Thanks for reading and keep those fridges and backlogs clean and fresh!
Special thanks to fellow Goodreaders William Cline, Morgan Russell, and Eric Lin for their insightful feedback on this blog. Also thanks to my good friend Mónica, who reminded me that my last blog post was older than her daughter. It was a nice push to finally get this out in the world.
Note: this article originally appeared on my tech blog, DePhillips Design.
