Your Product Backlog Is Full Of Garbage!
Who hasn’t heard that phrase? I wager everyone ever to write stories has been told by someone, they’re doing it wrong.
In my line of work I see Backlogs for many different products, maintained by many different people, employing many different styles. And it’s been eye-opening.
I’d like to share some observations with you. Some concerning best practices, some concerning commonly seen mistakes. And I don’t want to just preach to you, I’d like to make you think about why something is a good or bad practice, understand the consequences of your choices in the matter, and be ready to adapt your workflow to your unique context.
As a third installment of this series, let’s talk about…
How To Avoid Filling Your Backlog Up With Trash
When I open a random backlog, something I frequently find is a long list of issues. Most of them old, deprecated, redundant, or incomprehensible.
Why is that? It’s because we tend to recoil at the thought of throwing out the trash. Because we misuse our backlog as some sort of notebook. Because we were told to add something to the backlog, and caved. Because we had a brainfart idea last night after two bottles of wine.
Backlog maintenance is an important part of our jobs, if we neglect it, we lose visibility of the scope, we can’t tell how much of it is done, when we’ll land it, what’s important, what’s not.
But those are precisely the reasons we even have a product backlog in the first place. So, what to do?
Regular Maintenance Sweeps
Make it a ritual of sorts to go through your backlog, every single day, and sort out the trash.
Yet, what about things we can’t tell whether they are important? Or we aren’t sure we won’t lose them if we throw them out now?
Do not treat the backlog as a wishlist. It’s not. If you need a wishlist, keep a separate document where you track wishes. Do a pass on your backlog to see what’s merely a wish of someone, and what you consider in scope. If it’s not, move it out.
Structure Your Backlog
For large products with high throughput, several streams, long roadmaps, you may want to avoid having one ginormous kilometer-long monstrosity of a backlog and instead introduce chapters and verticals to it if you need to.
Milestones and Feature Teams are common approaches to deal with this horizontally and vertically. Research what makes sense for your setup, don’t leave your backlog out to hang.
Adequately Label Your Artifacts
Names have power. Whatever setup you use for your backlog management, at least one thing they all have in common: your issues get to have a headline, or name, each.
There are many ways you can name a given issue, but some are more useful than others. One way I always find useful is to call a story by its outcome.
“The User Can Enter The Building” would be a story calling for a door.
If I were to write another story calling for another means of entering the building, or a better door, I’ll automatically collide with the previous one, making redundancy, and iterations obvious.
This makes the backlog very readable, and if I were to change my mind and no longer wish for a door, but instead a tunnel, I’ll quickly find what story to change, rather than being compelled to just create some “make tunnel” story. It’s important to keep track of conflicts and deprecation.
Similarly, “add login button” is not a sensible name for a story, all be it accurate, and true to its content. “User Can Initiate Login Process” is the true outcome, the login button is merely the output, the vehicle delivering the outcome.
Introducing iteration identifiers with your stories may also prove advantageous. “The User Can Enter The Building [1]” would be a lesser iteration of “The User Can Enter The Building [4]”. One calling for a hole in the wall, the other for an automatic rotating door.
If you’re not comfortable numbering your iterations, use compound names, or associate them with an epic instead.
That brings us to the topic of epics. Epics can have many meanings, but let’s go with the most popular convention here: “Epics are large user stories.” nothing more, nothing less.
A story is thus fundamentally the same as an epic, so don’t force yourself to associate every story with some higher level of hierarchy, like an epic. Otherwise you’ll end up with 9999 Epics, many of which contain exactly 1 story. Your mileage may vary.
Some people consider “epics” to be what I’d rather call “theme”.
“Access” might be a common theme between “The User Can Enter The Building” and “The User Can Open The Strongbox”, but you can tell, these two stories seem hardly related in the value they deliver. They may not even belong to the same solution.
Think In Terms Of Solutions And Fragments
To pick up our popular example “The User Can Enter The Building”, we could say that this is an outcome that needs to be produced by something. This something is a “Solution” to the problem “The user cannot enter the building.”
A given problem may have multiple solutions, each delivering the desired value not only in varying levels of sophistication, but also have varying side effects, synergies etc.
As a Product Owner, often times at conception you do not know what solution will ultimately be the one you will get. You might not even have a solution in mind at all. Mark those stories that represent an entire solution, versus stories that only represent a fragment of a solution. You’ll find yourself with less garbage issues in your backlog.
Don’t Let Bugs Swarm Your Backlog
Regularly go through your bugs. If you keep them living in your backlog, you need to keep house. These pesky little critters don’t go away by themselves, instead they multiply.
Hunt them down, every single one. Classify them.
- Breaks The Product -> Fix it immediately.
- Breaks The Solution -> Fix it immediately
- Breaks The Fragment -> Fix it immediately
- Inconveniences The User -> Turn into a story, or defer, or accept.
- Cosmetic -> Turn into a story, or defer, or accept.
- Design Flaw -> Turn into a story, or defer, or accept.
Don’t leave bugs idling around. Sometimes this is referred to as “Zero Defects Policy”.
Also important: Don’t treat things as bugs that are not, in fact, bugs.
A story that fails to pass a test, any test, including regression test, does not produce a bug, it’s just not done. Bugs can only be caught in a build after it passed tests. (Bugs are defects not caught in test cases ).
Do yourself a favor and don’t accept builds that are defective. Debt does compound and grow. Bugs are debt. Use your best judgment.
If you accept a defective build, all its known defects become bugs. See above.
And yes, bugs may be found during development. Attempting to implement something new can expose a bug that was already there to begin with. That’s fine. Classify it right away.
Have more tips on how to avoid cluttering your backlog? Got some questions regarding the matter? Share in the comments!
Thanks for reading, until next time!
