Backlog Items Age Like Milk, Not Wine

The older your Product Backlog Item gets, the more irrelevant it?becomes

Do you have dozens or hundreds of items in your Product?Backlog?

Do your backlog items last a couple of months or several months, if not?years?

Do you remove old items from your backlog or move them to the?bottom?

The more on the left your answers are, the higher your chances of innovating become.

The more on the right your answers are, the more feature-factory your team is.

Be Careful! Backlog Items DO NOT Age Like?Wine

If you’re a wine fan or at least understand a bit about it, you know that the older the wine gets, the better it becomes. Wine collectors keep bottles stored for decades, and the wine will become fancier and increase its value several times. That is how it works with wine and not how it works with Product Backlog Items.

Funny enough, I’ve observed some weird patterns with many teams:

• Once an item goes into the Product Backlog, it only goes out if the team implements something out of it. Otherwise, it will remain there for the “future” when the team has the capacity for it
• Nobody dares to remove any backlog item because they are afraid of wasting their work
• Product Backlogs become a vast list of everything once talked with several people who are not even in the company any longer

I feel like people perceive backlog items as wine. The older it gets, the better it becomes. Sorry to say that, but this is bullshit. From my experience, treating backlog items like wine will lead to:

• Distractions managing an extensive list of irrelevant items
• Managing the backlog becomes more important than addressing learnings
• Team members become confused about what matters most because the backlog is a list of everything you can imagine
• The backlog size pressures the team, and they focus on delivering more items instead of learning and removing outdated ones
• Teams become feature factories
• Product Managers fall to Backlog Managers because almost half of their time is spent doing bullshit management, ops backlog management
• Pointless discussions happen due to over-refinement of outdated items

Keeping a monstrous Product Backlog is the right way to fall into waterfall mode. Following a plan becomes more important than continuously adapting to your learnings.

There’s nothing brave in keeping an extensive list of everything. This is the right way of creating distractions instead of uncovering and focusing on what matters most.

Managing the Product Backlog can be daunting and stressful. I don’t aim to give you a perfect solution within this article, but to summarize the points you must pay particular attention to. That said, let me give you some food for thought and borrow a sentence from Maarten Dalmijn .

“When you don’t own your Product Backlog, it owns you.” How to deal with an absolute unit of a Product?Backlog?

Backlog Items Age Like?Milk

How long does milk last? After opening a bottle, the milk lasts a maximum of four days. After that, it’s spoiled, and you should not drink the milk unless you are careless about your health.

I think Product Backlog Items are similar to milk. Once you “open” it, you either move on with it, or it will spoil. Old items get outdated fast, and as you learn from end-users, new relevant items emerge, and that’s where your attention should go.

Let me elaborate on what makes backlog items’ lives so short:

• Product development is complex. We simply don’t know what we don’t know. That means we frequently learn something new and should adapt our backlog accordingly
• The more your product evolves, the more outdated your old backlog items become
• Agile is about speeding up the learning time. Keeping old items in your Product Backlog is a sign you’re either not learning fast enough or following a plan instead of addressing your discoveries
• Old backlog items force you to focus on the past instead of the future
• An extensive Product Backlog impedes you from focusing on reaching your goals

It might be uncomfortable to keep a lean Product Backlog. It creates a feeling of lacking a plan, and we are constantly uncertain about what to do next. And that’s precisely the magic of a lean Product Backlog; we focus on learning and creating items we can work on.

Embracing uncertainty is what enables teams to innovate. While following a plan is what limits teams to mediocrity.

One of the critical aspects is understanding what a Lean Backlog is and how to get there. I wrote several pieces about how you can meaningfully deal with your Product Backlog. Let me take a quote from these articles to make my point sharper.

I perceive any Product Backlog with more than three Sprints of work as extensive. If a Product Backlog has more items than the Scrum team can take in a couple of Sprints, it’s a symptom that planning is more important than learning. — Deleting the Product Backlog Is Your Salvation to Be?Agile

Sustainable Backlog Management

High-performing teams don’t care a lot about managing the Product Backlog. They will care about reducing their learning cycle and taking action to create value.

The Product Backlog is a means to an end. The goal isn’t to have a plan to follow but to uncover what creates value and ensure you delight end-users and help businesses grow.

When you spend too much time managing your Product Backlog, you have too little time to do what matters most; delivering value sooner.

“Keep the Product Backlog clean. Backlog items age like milk, not like wine” — Agile Product Manifesto

Over the years, I developed a strategy to keep the Product Backlog clean, and here is my strategy:

1. Define a clear goal: it doesn’t matter the format. You need to have a goal your team will follow. It’s essential to have the outcome in mind and not only the output.
2. Adapt your Product Backlog according to your goal: only allow items related to your goal to remain on the Product Backlog, everything else is a distraction, and you can remove them.
3. Define what old for you is: the definition of an old item will vary according to the speed it takes for you to learn from your audience. The faster you learn, the quicker your backlog items become outdated. I think a timespan of two to four months is sustainable.
4. Create a routine to remove the old: take half an hour of your time once a week and clean up your Product Backlog. Remove everything old or unrelated to your Product Goal.

The leaner your Product Backlog is, the less pressure you feel, and the more space for the news you?create.

One More?Thing

Backlog Management is vital to creating value, and you can find thousands of articles about it. Let me share some practical pieces to help you thrive:

• No, You Don’t Need More Than 4 Hours a Week to Manage Your Product Backlog
• Myth: The Product Backlog is maintained exclusively by the Product Owner
• A large Product Backlog is pointless
• Myth: In Scrum, the Product Backlog has to consist of User Stories
• Product Backlog Management: what must a Product Owner avoid?