Product backlogs are an invaluable way to gather ideas and capture inbound bugs from other stakeholders in the organization.

Not only that, as product managers, we heavily rely on our backlogs. We use backlogs to determine what’s ready to be loaded into the next sprint, what ideas need more grooming, and which initiatives should be postponed.

Yet, one of the problems with product backlogs is that they overflow very quickly. Ideas get placed in the backlog, and endless streams of tickets come in through all corners of the organization – yet, very few of these tickets ever get reviewed.

A disorganized backlog is a backlog that slows down the development team and causes confusion to stakeholders. Therefore, healthy backlogs are incredibly valuable.

So how do we maintain healthy backlogs?

Keeping Your Backlog Healthy

The goal of your backlog is to track items that are “to be done”, but are not yet actively being worked on.

While this is easy in principle, the problem is that in the real world, backlogs usually hold 3 kinds of tickets:

1. Tickets that are groomed but deferred (that is, ready to be slotted into an upcoming sprint)
2. Tickets that are prioritized but not yet groomed
3. Tickets that have never been reviewed

These tickets are usually all treated the same, rather than thoughtfully separated and independently maintained. To ensure healthy backlogs, we need to consider each of these kinds of tickets on their own.

So, let’s break down the approach for each kind of ticket.

To manage “groomed but deferred” tickets, create sprint N+1 and N+2 before your current sprint N ends. When sprint N closes, kick off sprint N+1, and create sprint N+3 immediately afterwards. These placeholder future sprints hold the tentative priority for your “groomed but deferred” tickets.

For example, let’s say I’m currently in Sprint 14. I’ll create Sprint 15 and Sprint 16 and load both of them with tentative priorities.

Then, as soon as I close Sprint 14, I’ll kick off Sprint 15, create Sprint 17, and load Sprint 17 with tentative priorities.

There are a couple of benefits of slotting groomed tickets into future sprints.

First, they’re lifted out of the “working area” of the backlog, which means that now your backlog is truly meant for items that require additional thought and review. By reducing the scope of your backlog, you increase its health.

Second, you provide additional clarity across your entire organization on what you’re planning to tackle next. Healthy backlogs easily broadcast priorities, and you can always point to your backlog as the source of truth for where your team is headed.

No tickets should ever enter future placeholder sprints if they’re not groomed yet. Never commit yourself or your team to work that is not clearly defined.

Next up – to manage “prioritized but ungroomed” tickets and “not yet reviewed” tickets, create dummy “divider” tickets in your backlog with the following names:

1. — PRIORITIZED BUT NOT YET GROOMED —
2. — NOT YET REVIEWED —
3. — END OF BACKLOG —

These divider tickets provide a visual cutoff for categorizing the tickets in your backlog.

The dashes in the name are surprisingly helpful! They enable you to easily denote the different categories, as they visually interrupt your eyes when you scan through your backlog. Remember that well-organized backlogs are healthy backlogs.

So, let’s talk through how to use these three dividers.

None of your tickets should ever be above the “prioritized but not yet groomed” line, or below the “end of backlog” line. If they are, you know that they belong somewhere else. This can happen sometimes where a developer meant to file a bug into an existing sprint, but the ticket falls into the backlog because the sprint wasn’t added to the ticket.

I think of the lifecycle of a ticket this way: 1) capture the idea in the backlog, 2) prioritize the idea, 3) groom and flesh out requirements, 4) re-prioritize based on the full set of requirements, and finally 5) load into a sprint to be completed.

Therefore, you should only groom tickets that are prioritized, in priority order. You should never spend time grooming a ticket if you don’t have a good sense of the priority.

After all, if you spend time fleshing out a ticket that winds up as low priority, you’ve sunk all of that time into a low-impact item.

Even worse, you might feel that the ticket is more important than it actually is, due to the sunk-cost fallacy. You may feel that since you put so much effort into the ticket, why not complete it? The reason you shouldn’t complete it is because other tickets provide more impact for your organization.

Once a ticket is groomed, it should sit in one of the placeholder sprints you’ve created, and not in the backlog. Again, the goal is to maintain a healthy backlog that is a “working area” for items that are not yet ready to go.

Furthermore, on a regular basis, you should review tickets under “not yet reviewed” and force-rank them under “prioritized but not yet groomed”. We’ll discuss a couple of mechanisms for reviewing tickets in the next section.

As a final note here, you’ll find that over time, tickets might not fit in any of these categories anymore (e.g. they’re permanently “won’t do”, based on strategic shifts or changes in business context). Close them out so that they don’t clutter up your backlog. Again, by removing dead tickets, you’ll ensure your backlog is happy and healthy.

Best Practices for Reviewing Priorities

It’s your call whether to work through your backlog from “bottom to top” or “top to bottom”. That is, you can either start from the last ticket and work your way up, or you can start from the first ticket and work your way down.

“Bottom to top” helps catch any missed tickets, but the tradeoff is that you use up most of your mental energy by the time you get to your most important tickets near the top.

On the flip side, “top to bottom” means that you’re always looking at your most important tickets (which will generally be well-groomed already) but that you’ll run out of energy or bandwidth by the time you get to the bottom of your backlog. This can cause stakeholders to complain that your backlog is a black hole. Their tickets will usually sit at the bottom of your backlog, which means that you never get to them.

Personally, I like to alternate between days. One day is “bottom to top” to check for any lost tickets. Then the next day, I go from top to bottom to ensure priorities are straight and tickets are groomed for sprints N+1 and N+2.

Final Thoughts

By being disciplined about the priority of the work that your team will tackle, you provide transparency and accountability across your entire organization.

While it may feel repetitive or boring to prioritize and groom your tickets, your output as a PM is the quality of the decisions you make. Ticket priorities and requirements are decisions that you make – regardless of whether you make them actively or passively.

As you continue to manage your backlog with discipline, you and your team will start to find prioritization and organization easier, and you’ll be more and more in sync with one another. The time investment is well worth it!

 

---

Have thoughts that you’d like to contribute around maintaining healthy backlogs? Chat with other product managers around the world in our PMHQ Community!