👋 Hey, it’s András here! Every two weeks, I write about product management concepts, hot takes, and frameworks to help you build better products. Subscribe to get each article delivered to you when it’s published!

Subscribe now

Backlog grooming or refinement is the act of enhancing, estimating, and prioritizing the possible work items of a product team. So, what’s usually wrong with those ceremonies? Many things!

First, backlogs are often ever-expanding lists, slowly becoming the facades of real prioritization. In theory, the backlog is there, nice and groomed. But in reality, it’s messy, contains outdated items, and it’s hard to figure out what really matters outside of the top few things to be addressed next.

Second, the ceremony becomes a too comfortable habit through regular meeting invites. Just because the team is “agile” and many colleagues came from places where there was a backlog refinement before, there needs to be one here too. But is it checked whether the team really gets the benefits out of such a session?

Third, discussing and estimating new items take up too much time. Since many backlog items will never get delivered, teams spend an excessive amount of time discussing and estimating. Why spend this effort per item if most of those will never see the light of day?

What’s on your backlog?

To understand how to combat the effects mentioned above, first, we need to take a look at where backlog items are coming from. Often, there are two sources: new product requirements and technical items.

Here, product requirements define new solution ideas, problems to discover, and other wishes. On the other hand, technical items are more specific improvements that can help scale, enable new capabilities, fix bugs, or improve the way to develop software.

Both types of items are valuable, but should they be on the backlog? The scrum guide describes “product backlog” in the following way:

“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”

At best, it’s a blurry explanation.

But one thing this definition DOES NOT state is that the product backlog should contain all the possible work items and half-baked ideas. And that’s the first mistake product teams can make with backlogs.

It’s easy to fall victim to recording all the good ideas (from which there are usually many) to avoid forgetting them. But in reality, most items won’t get addressed in the short- or medium-term. So then, the backlog becomes a collection of far-reaching ideas mixed with actual, near-term work that is important to carry out.

And that’s very messy to handle!

On top of this, if the backlog is treated this way, every additional grooming session will just make it harder to separate actual priorities from the noise.

Ideas are not equal to next priorities

To avoid a convoluted backlog, keep ideas in a separate place. Use the backlog to visualize the next few months of planned work in priority order.

While this sounds easy in theory, it needs rigor and thoughtfulness in practice.

First, set up a place where it’s easy for everyone to record new ideas. You want to make sure that it’s also fast to convert ideas to work items and the other way around. We want to remove friction from the process, and if an idea’s details need to be copy-pasted every time from one tool to another, the approach will likely never get adopted. An additional Jira status, a spreadsheet with different tabs, anything works as long as there is enough separation.

Second, product requirements and technical ideas can be stored in the same place, although I’d recommend separating, grouping, or labeling them. A new feature idea with customer insights is very different from addressing technical debt. Plus, putting the items into topical buckets can ensure that the list remains navigable and it doesn’t just become a bloated list of forgotten ideas.

Once we have separate backlog and idea buckets, check that everything is in the right one: ideas that might not happen until next year shouldn’t be on our backlog, and things we’re addressing next should be clear, visible, and prioritized. For this, let’s define a backlog timeframe: how many months of work we’d like to keep in the backlog.

I’d recommend 3 months—one fiscal quarter.

Then, go through the legacy backlog once to move out all the ideas from there. This will be a long and tedious exercise, but one that’s worth it once. And this again signifies why it should be effortless to transition work items to ideas.

After we’re done with the one-time exercise, future backlog refinement sessions should be more critical. When evaluating new items, those should only make it to the backlog when we’re confident they’ll be dealt with in our defined timeframe.

Almost every new item is a good suggestion, but we cannot deliver everything as all teams have limited capacity. A few questions that can aid the decision-making here:

Is this something that we’ll confidentially tackle in the next X months?
Is this something that’s necessary for our planned deliverables?
If we take this in, would we need to deprioritize something else? Would that deprioritization affect any major plans or commitments?
What happens if we don’t address this in the near term, or at all?
Why didn’t we plan with this before in the first place?
If we delay this, can we still reasonably expect to hit our goals?

After asking similar questions, we should have a hunch that something should go to our backlog or be recorded as an idea. One response we might receive to these is…

“But it’s a quick thing, let’s do it now!”

Which is fine, as long as not every second or third item is like that. There are quick wins that are better addressed on the spot rather than waiting months and losing the context.

For the estimation, we shouldn’t spend too much time guessing the size of the ideas. The scope there is often fuzzy, so estimating them this early is not practical. Instead, use T-shirt size estimations (S, M, L, XL) or task/story/epic distinctions to understand the effort. That’s probably enough at this phase.

Next, let’s look at how to keep the backlog and the idea lists organized beyond the recurring backlog refinement ceremony.

Going through the whole thing once in a while

To ensure that the backlog and idea lists remain relevant and manageable, we should allocate some time to review them at least every few months.

For the backlog, even if we’re strict about moving items there, we might still end up with a few things that we thought were important but ended up not doing. This is normal, and a casual review is an excellent opportunity to revisit priorities—and if some backlog items should be rather moved to ideas. These issues can be minor technical improvements or features that just never got to the top.

In addition, a recurring review is needed with the idea list(s) too. While we’ve purposefully deprioritized items in the past, we might have discovered additional needs since then. If that’s the case, it’s reasonable to move some items to our backlog or plan with those for future quarters. And, if we realize that something has already been addressed, the idea item can be deleted.

When working with a product team and recurring delivery cycles (like a quarter), the best time to revisit the ideas section is before the start of the next cycle.

The backlog and its ranking are good reminders that there are no separate priorities for technical items and new product requirements. We have one team, and they must decide whether to work on the next best features or address something technical. And product managers should be able to adequately prioritize the upcoming work with technical leads.

Key points

Remember the following to make sure that there is a good focus in your product team:

Store product requirements and technical ideas separately from the backlog. The backlog should only contain items that will be confidently addressed in the next few months.
Be critical about new items during the backlog refinement. Remind yourself that most ideas are good, but any team’s capacity is limited; therefore, you need to prioritize.
Go through the list of ideas once in a while to see what to consider for the future. There might be timely, hidden gems or even items that are no longer needed.

A Practical Approach to Backlog Grooming