Why a fresh backlog will make your product better

Filipe Albero Pomar
Agile Insider
Published in
3 min readJun 10, 2022

--

Learn to quantify how bad (or good) your Product Backlog really is.

Photo by JESHOOTS.COM on Unsplash

The goal of agile is to address uncertainty, respond to change and deliver value incrementally. We accept that we cannot fully define a product before starting to build it.

Then why are our product backlogs so long?

From my experience, most teams will have more user stories than they can ever deliver. Their backlogs become sad dumping grounds. And it’s also difficult to properly prioritise everything. A stale backlog adds to the team’s cognitive load and the bulk of it is simply ignored.

Using the DEEP acronym is a good starting point to a healthy backlog. It means, that a backlog is:

(D)etailed appropriately
(E)stimated
(E)mergent
(P)rioritised

The conundrum is that it’s difficult to quantify those things. What does “appropriately” mean exactly? How “emergent” is emergent? You should even refine the backlog like Scrum says. But when do you stop?

What can you do then…?

I have been playing with the idea of “backlog freshness”.

A “backlog freshness” is the percentage of the backlog that has been created recently.

For example, my new team’s backlog is only 7% fresh. Let’s work that out. We have 84 user stories to do. Out of those, only 6 were created recently (in the last 45 days). The maths is rather simple 6 / 84 = 0.07, which is 7% fresh.

Tell me if that resonates with you. The bulk of that backlog was written by a previous generation of Product Owners and developers. Priorities have changed. Many tickets are outdated. And everyone ignores the bulk of the backlog. That means we have an illusion of having lots of work to do. Whilst, in reality, no one really knows how much of it is necessary.

So, you have two options to make a backlog fresh again:

  • delay creating stories until they are needed (e.g., 1 to 2 sprints before)
  • fearlessly prune your backlog (e.g., delete anything not clearly important, AND delete anything unlikely to go in the upcoming sprints)

(I hear the hoarders out there screaming in despair. For you, the better option might be to hide things elsewhere instead of deleting them. As long they are out of sight from the team, that’s OK)

Your new fresh backlog will keep everyone focused. It means Product Owners will only write tickets that are likely to be worked on. The team becomes aligned with what’s important. And the product might even benefit because it’s easier to prioritise (i.e., things are "fresh" in everyone’s minds).

Now think about your backlog. How fresh it is? And do you think there is a freshness number to aspire to? Is it 100%?

I am curious to hear your thoughts on this.

--

--

Filipe Albero Pomar
Agile Insider

I'm passionate about products and growing talent. My mission: to build teams that are predictable, transparent and engaged. 🚀 Engineering Manager at Maersk