It’s Time to Declare Backlog Bankruptcy

Apr 12, 2023

Calendar Bankruptcy. Goal Bankruptcy. Why not Backlog Bankruptcy?

We abuse our Backlogs, treating them like junk drawers, and carrying around 10’s, 100’s, 1000’s 😱 of items that are never prioritized … and probably never will be. And then we act like hoarders. We won’t let them go. We get emotional about them. We fight to keep them.

We aren’t being honest with ourselves, our team, our stakeholders … the vast majority of the backlog will never be done. Some of them might even be already done or overcome by events (OBE), and we’re still carrying them around!

We aren’t honest about the quality of the old stories in our backlog either. Just like produce, the longer it sits around the more dubious its freshness. Stories we wrote six months, a year, two years … five years ago, are more likely to cause harm than good if we ever do get around to them. Our context has changed and so have we as individuals and teams. If we ever do get around to that work, we’ll write much better stories then than the ones we’re fighting to keep.

And what would your backlog look like if you were still using analog tools, i.e., sticky notes and markers? Would you have hundreds of them on a wall somewhere? In a file folder, a drawer, a bag of some kind? Would you need Hermione’s magic bag from the Deathly Hallow’s? I don’t think so. I sure hope not anyway.

I don’t think we can, or should, prioritize and plan against a large backlog containing a hodgepodge of items that represent a myriad of future states or objectives for our products.

Declare Backlog Bankruptcy and LET … IT … GO.

Purge your backlog of that pile of Stories, Bugs, and who knows what that you don’t need to deliver the value immediately ahead of you on your roadmap.

Am I alone in my opinion? Is declaring Backlog Bankruptcy based in solid agile practices?

What is a Product Backlog?

Scrum.org says

As described in the Scrum Guide, the Product Backlog is an emergent, ordered list of what is needed to improve the product.1

scruminc says

The Product Backlog is a prioritized list of everything that might be included in a product. The Product Owner creates, maintains, and regularly re-orders the Product Backlog to align with the Product Goal.2

Agile Alliance says

A product backlog is 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.3

So a Product Backlog is an emergent, prioritized list of what is needed or might be included in the product, aligned with the a specific outcome or Product Goal.

So, what is a Product Goal?

Scrum.org says

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.4

scruminc says the same and adds

“The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.”5

Product Goal = a specific objective/future state of the product. Got it.

What do others say about large backlogs?

Shape Up says

Backlogs are a big weight we don’t need to carry. … Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.6

Roman Pichler says

You should therefore strive to keep your product backlog as concise as possible whenever your product faces uncertainty and change—be it market, business, or technology related. The following three techniques will help you with this: First, group related items into themes. Second, keep lower-priority items coarse grained. Third and most importantly, focus the backlog on a specific product goal. Then decline and remove items that do not serve this goal, as I discuss below.7

Agile Alliance says

It’s possible for a product backlog to get too large to be effectively managed. This happens if a team adds every idea that gets suggested for addressing the outcome but never explores the ideas or removes the items that won’t be delivered. Product backlogs can also grow to an unmanageable size if all large product backlog items are split into smaller product backlog items too far in advance of when the team will work on them.8

Agile Alliance also says

It should be cheap and fast to add a product backlog item to the product backlog, and it should be equally as easy to remove a product backlog item that does not result in direct progress to achieving the desired outcome or enable progress toward the outcome.9

Scrum Alliance says

As the product backlog grows larger:
The lead time grows.
The number of dependencies also increases lead time by creating delays.
Product backlog refinement takes longer. … As product backlog refinement takes longer, team members become less engaged. … As they become disengaged, they have a reduced understanding of the product backlog Items and are more likely to build a version of an item differently from what the customer wanted. Finally, as product backlog refinement takes longer, it is more likely that the team will misplace items that have become buried.
Prioritization becomes challenging.
Pruning dead items becomes harder. As the product backlog grows larger, it becomes harder to spot the dead items (i.e. items that are no longer relevant). As dead backlog Items get missed, the product backlog grows ever larger in size. This is called a negatively reinforcing feedback loop.10

So … large backlogs are not good and you might even say they aren’t agile.

Looks like I’m not alone and declaring Backlog Bankruptcy is aligned with solid agile practices.

Better Ways

I worked through this with my team at the beginning of the year. We’d taken a few small steps over the past year and a half and we finally took one last big step. Now our backlog is eight Stories and seven Epics!

In my opinion, a small, emergent backlog of stories written just-in-time to deliver on a specific outcome is a better way.

P.S. Pairing a small backlog with a Suitably Detailed Roadmap makes a lot of sense to me and is probably a better, better way.