How I refine my backlog

If a cluttered desk is a sign of a cluttered mind, what's a cluttered backlog?

I know backlogs aren't very popular. Yet, in some organisations, they're necessary (or imposed). We might as well learn to keep them tidy & actionable.

Here's my simple backlog refining process.

---

Tools

The tools you use will influence this process, but only in the detail.

If you use Jira, for example, you might have to do steps manually, while Productboard might have a specific feature.

Sample backlog on Productboard

The principles behind this approach will work regardless.

Create a backlog refinement cadence

By definition, you're never 'done' refining a backlog.

Backlogs go out of date regularly and are, almost by default, inefficient (hence the hate).

This makes creating a backlog refinement cadence all the more important. Here's my preferred cadence:

• Once a week, refine enhancements and bugs.

• Once a month, refine larger epics.

This regular work keeps things from getting out of hand.

Block these times in your calendar so you never skip them. I cannot stress how easy it is to lose control.

Aim for a DEEP backlog

Roman Pichler's DEEP backlog is an excellent (and my go-to) target for your refinement sessions.

DEEP stands for:

• Detailed appropriate

• Estimated

• Emergent

• Prioritised

During a backlog refinement session, I work through each ticket individually until they all reach the desired DEEP status.

Here's how I do this in practice.

Step 1: Refining enhancements and bugs

I recommend refining bugs and enhancements every week. These tickets are the most 'volatile' and likely to be out-of-date, so a faster cadence makes sense.

Pull up your list of enhancement tickets. For each ticket:

1. Check its creation date. If the ticket has been in the backlog for a long time (e.g. one year) with no action, delete it. Show no mercy. If it turns out to be important, it will come up again.

2. Make sure you understand it. Any ticket you don't understand goes to the back of the list.

3. Check for duplicates. Let's say you find the following ticket: "Make the login button green". Search your backlog for keywords ('login', 'green', etc.) for tickets with similar requirements. Keep one.

4. Write an appropriately detailed description. I define 'appropriately' below.

5. Summarise and quantify interest.

   1. Track each time a customer makes an enhancement request. Add the request to the ticket, along with some context. If you need to do this manually, create a table in the ticket description and add a row for each request.

   2. Quantifying interest helps you prioritise your backlog (DEEP). Tools like Productboard will do this for you by assigning a value per insight attached to a ticket. Alternatively, you can do this manually by adding a number at the start of the ticket name and increasing it with every request (‘4 - Make login button green’).

6. Order your enhancement backlog. I organise mine in descending order, from most to least requested.

Your 'I don't know what the hell this is supposed to mean' tickets are at the bottom of the list. Speak with colleagues (devs, customer service, etc.) to figure them out.

If you still can't understand them, throw them in the bin.

Congratulations, you've refined your enhancements backlog!

Now, bug tickets:

1. Replicate the bug. If you can't, delete it.

2. Check for duplicates.

3. Write a detailed step-by-step on how to replicate the bug.

4. Ideally, attach a video walk-through of the bug. I like to use Loom for these.

Prioritising bugs is trickier than enhancements. Use judgment to evaluate urgency and impact. There are no formulas or secret sauces here.

Congratulations, you've refined your bugs backlog!

Step 2: Refining epics

Epics should be closely tied to your product strategy and more focused on the long term. As such, your epic refinement cadence can be slower.

Nonetheless, if left unattended for too long, epics will rot away in your backlog. I like to review them monthly.

Let's get to work. For each epic:

1. Assess its place in the wider product strategy. If an epic no longer aligns with the long-term plan of the team (or the business), delete it.

2. Make it DEEP. Each epic should have a description and estimation.

3. Prioritise the backlog. This should, again, be done at the strategy level. Reminder: you don't need a prioritisation framework.

I like to organise my epics backlog in descending chronological order. At the top, I have my current and next epics. Then, as you work down the list, you see further and further into the future.

What does 'detailed appropriately' mean?

"Alex, this all sounds like a lot of work. There's no chance I'll ever get through our entire backlog. This is insane."

Hold your horses.

This is where the keyword appropriate comes in.

Remember, the DEEP framework requires each ticket to be 'detailed appropriately'.

In practice, this means you don't need insane levels of detail for every single ticket. That would be impossible.

Instead, the top of your backlog (the most important, relevant, and upcoming work) should have a very high level of detail. The further down your backlog, the rougher details.

Visualisation of a refined backlog

For example:

• Epics at the top of your backlog: comprehensive descriptions, PRDs, user stories, and GTM.

• Epics in the middle of your backlog: comprehensive description, PRD, and rough stories.

• Epics at the bottom of your backlog: rough description, goals, and constraints.

With this caveat, you should be able to work through your entire backlog each session. You also avoid wasting time on tickets/epics that may eventually get nuked.

A word of warning.

Your first few backlog refinement sessions might be brutal. If your backlog has been festering for weeks, months, or years, it'll take time to get it back to a decent standard.

Don't be discouraged. We all start somewhere. Pick one ticket and get to work. I recommend blocking out a few days to get through it all in one go for the first time, then refer to your cadence.