Resources > Articles

Your Backlog Is Too Long: Delete It!

Author
your backlog is too long delete it

Your backlog is too long. You know it and your team knows it. Neglected items from two years ago are in there collecting dust. Long-forgotten issues that may or may not have been fixed are festering in the chaotic dungeon of your backlog. Delete them.

“As a database, I would like to support Acme Standard ZXY 2.17-3.”  Huh? What does ZXY 2.17-3 do? What does it mean? No value, no stakeholder. Delete it.

Product management often uses the backlog as a notepad, a place to jot down tasks before they slip from consciousness. Stop. Every item in your backlog has to be sorted, and you’re a human bubble sort (so inefficient your primary purpose is to show computer science students how not to sort lists). The fewer stories you have, the more meaningful they can be.

Task management systems like Getting Things Done encourage consolidating everything into one place to deal with later. Your backlog should not be one of these places. A large backlog slows your velocity, confuses your team and obfuscates your progress.

I once took over a three-year-old project and its backlog. As a new member on the team, I didn’t want to rock the boat. I read every issue, added structure that wasn’t there and tried to figure out themes from clues the old product manager had left behind. After two months, I’d cleaned things up. Each sprint had a strong goal, and the team was making progress. But things would get lost. Bugs that I knew were there were consumed by the black mass at the bottom of the list. I’d find three bugs created by different team members within a day of each other; apparently finding the original bug was harder than making a new one.

If you have these issues, it’s time to delete half your backlog. But how do you decide what’s important and what’s not?

If it doesn’t have a who, what and why, delete it. It’s not worth keeping stories without stakeholders, work or necessity. I cleared out 30 percent of my inherited backlog by following this mantra. Often technical debt will be tracked in the backlog without any justification for its importance. If you’re creating a technical debt story, be sure to justify the exact reason the work is necessary. Will it improve performance? Solve a bug? Make further development easier? If you’re not sure, delete it.

If the team can’t remember whether it was fixed, delete it. If it’s not worth recalling, it’s not worth existing. A former team member placed 30 items in the backlog, and we weren’t sure what they were, or whether they were important. We realized that if we didn’t know what the bug was, and couldn’t verify it, we could either forget about it, or it would pop up later where we could fully spec it out. We deleted 10 percent of our backlog this way.

If a feature request hasn’t been updated in months, delete it. It belongs on a roadmap or planning page, not your backlog. Another 10 percent of our backlog was “someday” items. Often these items were well-written specifications, but we weren’t going to complete them within the next year. I transferred them to our planning pages.

Don’t be afraid to consolidate stories. Stories should be smaller at the top, and bigger at the bottom. We often forget that part. For example, my team created specs for an epic—20 stories that were too big to complete in a single sprint—and then realized we had to leave it alone for three months. What did we do? We threw it away. Products morph with every sprint. If and when we returned to that epic, the tasks would have been out of date and useless; we’d have carried them as dead weight the entire time.

I heard from my old product team recently. That old backlog of mine? Deleted. Entirely. I didn’t shed a tear.

Author

Author:

Other Resources in this Series

Most Recent

Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...
Creating a product roadmap: what should you include
Article

A Guide to Product Roadmaps: How to Build One That Works

A product roadmap is a frequent request from the sales force and others in the company. ‘What’s coming in the next release and the ones after that?’ Long buying cycles common with strategic products often...
Dry erase board with product roadmap drawn on it
Article

How to Build a Brilliant Visual Product Roadmap

Building roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. The good news is that there’s a better way. Executives have...
Product Datasheet
Article

How to Write a Kick-Butt Product Datasheet

If your datasheet passes the all-important skimming test, it's more likely that buyers will read it in detail. Here are 10 tips to help you write a datasheet that buyers actually read.

OTHER ArticleS

Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Subscribe

Subscribe