Honey, I Shrunk the Backlog

Five Tips For Trimming Your Product Backlog

This article is part of Maarten’s summer guest writer series. During my summer break from writing, I want to shine a spotlight on awesome content written by others.

I found the new product manager I was coaching in a conference room, piles of crumpled-up stickies and old notepads everywhere, the big monitor showing screenshots of prospective interfaces.

She had been bequeathed a massive, highly structured, comprehensive, and complex backlog for her product. With hundreds of items, covering years of conversations, it was like digging through the ruins of an ancient city, trying to discern pebbles from pottery fragments. She was struggling. 

It was only after dozens of refinements, customer interviews, three sprint plannings, and a host of other conversations that she finally felt comfortable enough to nuke the backlog, cutting almost 80% of the items from it. The change for her and the team was night and day. 

All this time, I had been giving her the absolute wrong advice—I told her to dig in and really, truly understand what was in that backlog. What I should have advised is what she ended up doing—getting rid of everything she didn’t need.

How to do it: Three Factors and Two Activation Modes

When trimming a backlog, I resonate with the software engineering principle You Ain’t Gonna Need It (YAGNI). YAGNI is one of the most powerful tools you have for reducing cognitive load - simply put, if something isn’t fit for purpose, needed in the near future, then you can take it off your active plate. 

Here are three factors I've found invaluable for downsizing your Product Backlog:

1. Aging. The older the item, the less relevant it likely is

2. Immediacy. Does the team need it now? 

3. Clarity and Size. Is it actionable, clear, and executable?        

Let me walk you through all of these three factors by starting with aging.

---

1. Aging

Some things just age…poorly. Anyone remember popped collars?

Look for items that have been sitting there,

moldering, for months (or years). Their history of being a permanent resident of your backlog makes it a pretty good bet that they are unlikely to get pulled into a sprint. Go ahead and retire these veterans - you can always put them somewhere safe, but non-visible, if you need to bring them back. 

2. Immediacy                 

While a backlog certainly has more than one purpose, its primary one is to provide work items for the product team (as well as overall context and visibility to stakeholders). For all these purposes, focusing the backlog on what is significant now, rather than what might be significant in the future, is more important than having everything you can think of in one list. 

Review each item: can you articulate the value, current utility to a customer, and how you’d execute on it now (or in the near future)? If the answer to any of these questions is “no”, either remove the item from the backlog, or rework it. This is a great way to determine what you need to refine. 

3. Clarity and Size

Roman Pichler often talks about making your backlog DEEP (Detailed appropriately, Estimated, Emergent, and Prioritized). This is powerful guidance, and I’d take it a step further than that! 

I’ve seen product managers create an “above / below the fold” in their backlogs, using a divider of some kind to separate out the executable portion from the rest. My favorite was a task called “BELOW HERE THERE BE DRAGONS” that had its own color, tags, and other markers to ensure folks understood that THIS was the line.

I’ve also seen product managers tag the non-executable items so they can veil/unveil them, and even move those items to a different list altogether. With any (or all) of these factors, you have the means to keep your backlog focused and trim. 

Next, let’s talk about how to get started, and how to maintain that backlog. 

---

How it Started - How it’s Going 

If you haven’t made a habit of pruning your backlog, getting started may be tricky. I call these ways to get going activators, and there are two broad techniques that work as activators. I commonly recommend that folks either respond to change, or to make it a regular habit, or both! 

1. Responding to Change (in team, in product direction, being the new product owner) 

This approach works because the purpose is the activator, which means less selling, pushing and cajoling your stakeholders into alignment. Here are just a few of the potential activators for pruning your backlog:

• You’re new to the product (congratulations!) 

• The market has changed

• A new technology is available

• Competitors have launched a game-changing feature

• Company strategy has pivoted

2. Regular Event (make it a habit to prune your backlog every quarter)

Like a good spring cleaning or an OKR review, make it a habit to review your backlog once a quarter, and prune the deadwood. This ensures that the work will happen, even if there’s no activating event. Even more important, it normalizes pruning your backlog. As with any habit it takes time and practice, but it is very worthwhile.

These tips and activators are approaches, strategies. They are designed to help you harness your most precious resource - your focus, so let’s talk about that. 

Starve your Distractions; Feed your Focus 

Backlog items that don’t drive value are a distraction and need to be removed from your field of vision. Move, remove, revise, until your backlog is streamlined, by which I mean pointed at the highest value work. Feed. Your. Focus. 

A critical note here: you do NOT need to keep a feature in your backlog “because we said we’d do it”. Backlogs are meant to be dynamic and responsive to change. If the need underlying that feature is no longer there, you have an obligation to remove that feature. Feed. Your. Focus. 

Starve your Distractions; Feed your Focus 

~ Daniel Goleman

And my friend, that Product Manager with the unmanageable backlog? Once she Konmari’d, we saw dramatic improvements. Refinement and planning were orders of magnitude faster. Development sped up. And the next version of that product that shipped was the most successful in the company's history. 

Was that all due to her dramatic backlog refactoring, of course not. But the focus, clarity and command that she had over that product, as a result of the pruning, was key for that team to achieve success. 

So - what’s MOST important resource - more data, more input, more hours in the day?

I don’t believe any of those rise to the very top. When I think about the most successful people in the product world, I bet most of them would agree - “Don’t think about where you spend your time - think about where you spend your focus.” And nothing drives more focus than a clear, concise, well ordered backlog.