What Is Backlog Grooming and How Do You Do It?

What Is a Backlog?

Before we can talk about backlog grooming, we first need to talk about the noun in that phrase. What exactly is a backlog?

As previously noted, most software teams have more work than they can do in any given cycle. For a lot of teams, the reality is that the list of work they could do is practically infinite. The backlog is the agile artifact that catalogs all of those different things the team could work on. For a lot of teams, their backlog is really long. This is a good thing; it means that people have ideas about how the team can improve the software they work on. The backlog serves a useful purpose as a catch-all for everything they could do to improve their software.

What Is Backlog Grooming?

In agile systems like scrum, teams engage with work in discrete units of time that they call "sprints." At the start of each sprint, the team picks some list of work of the backlog, which is the repository of all answers to the question "What can we work on?" The team commits to finishing work within the sprint, answering the question "What will we work on?"

Backlog grooming lives between these two questions. Astute readers will notice that there's a third question in between. That question is "What should we work on?" This is the question that backlog grooming intends to answer. It doesn't specifically try to answer when the team will complete a piece of work, nor how they'll complete that piece of work. Instead, it seeks to answer the question of whether a piece of work is ready for someone to work on it and the relative value of that piece of work.

What Should We Work on During Backlog Grooming?

One problem that I see a lot of agile teams face is failing to focus during their backlog grooming meetings. These meetings bloat, often taking up 90+ minutes of time from every developer, product manager, and project manager that works with the team. It seems like it should go without saying, but this isn't a great idea! So, let's talk about what your team needs to accomplish during their backlog grooming meetings.

Do: Ensure Tickets Are Scoped

This is a critical part of any backlog grooming meeting. You should look through any tickets that could conceivably be worked within the next 6-8 weeks—however many sprints that is for you—and ensure that each ticket is properly scoped. Properly scoped tickets feature a high-quality description of the work to perform, as well as a clear definition of "done." If there are extenuating factors or edge cases that the business wants the developer(s) to handle, they should be well documented, either in the ticket or in a publicly-available knowledge repository that the ticket links to.

One common pitfall teams experience during ticket scoping is finding out that the body of the ticket doesn't accurately represent the work the team needs to perform. Instead, the true negotiation of work happens in comments on the ticket, not the main body. During the backlog grooming, your team should ensure that each ticket accurately and comprehensively represents the work to be done in the body of the ticket itself. If there is information that's wrong or missing, a responsible party (usually a product manager) should be assigned to update the ticket before the team works on it.

Do: Order Tickets by Priority

In addition to ensuring that tickets are ready for the team, this is the other major work that you should undertake during a backlog grooming meeting. The goal of an agile software team (and truly any software team) is that the team should always be working on what's most important. The purpose of your backlog grooming meeting is to ensure that the most important work is at the top of the backlog. If it isn't, you should move it there during this meeting.

How do you know which work is the most important work? That's a great question, and a difficult one to answer. Sometimes, the most important work is work that lays the foundation for other important features. Other times, it's fixing bugs. In short, the most important work is the work that will bring the business the most value. If you're having difficulty figuring out which work is the most valuable for your team, Plutora's Business Intelligence is a great place to start.

Do: Figure Out How Long the Work Will Take

There are lots of ways to measure the relative work needed to complete a feature or fix a bug. This post isn't about getting into the relative value of those systems, but what I will say is that you should absolutely have a system. During your backlog grooming, your team should determine the relative difficulty of each item likely to be pulled from the backlog during the next 6-8 weeks. This relative difficulty helps you determine the actual value of each feature on the backlog.

What Shouldn't We Work on During Backlog Grooming?

As noted, it's common for teams to let their backlog grooming meetings grow out of control. Let's talk about how you can make sure that yours stay focused so they don't take up excessive time.

Don't: Design the Software

This is probably the biggest mistake I see software teams engage in. They seek to estimate the work necessary to finish the ticket. This is actually important; something that provides a fixed amount of value has wildly varying importance if that work will take one day to finish compared to if it will take one month. However, your goal during backlog grooming isn't to plan the work required in minute detail. Whenever two people in a meeting disagree about the work required to implement a feature or fix a bug, it's common for the team to dive into technical details. And it's easy to see why: technical details are a developer's stock in trade.

But it's up to the team to curtail these time-consuming technical conversations. If there is a very wide divergence in technical approaches, it's likely that you need to go back to ensuring that tickets are scoped before trying to groom them.

Don't: Litigate Business Decisions

This is a common temptation for software teams. Developers have their own sense of what work is most important or valuable for the team to engage in. That's not surprising, but it's also not healthy to argue about those things during a backlog grooming meeting. When you're setting the priority of items within the backlog, the primary determinant of value is going to be business value. Arguing over whether the business is appropriately assigning value to the work won't get you anywhere.

Don't: Try to Assign Work

This is another common pitfall for agile teams. Often, this is also a consequence of trying to figure out how long a particular backlog item will take. I've worked on code bases where, for various reasons, I was the local expert on a particular type of work. It makes determining the relative work for a ticket complicated when one person working on a ticket would take an hour and a different person would take a day or more.

However, you should resist the impulse to try to assign work during the backlog grooming meeting. That's not what you're here for. Instead, adopt a system of backlog estimation which defines relative work, and understand that each unit of relative work will not directly correspond to an amount of time spent on the ticket.

Make Backlog Grooming Work for You

Now that you have a better sense of what backlog grooming is, you should have a better sense of how to make it work for your team. Remember: your goal isn't to figure out every last detail. Instead, use this time to make sure that you understand how valuable backlog items are and how hard they'll be to complete. From there, you can prioritize that work, answering the question "What should we work on?"If you're struggling to determine which backlog features will provide your business the most value, Plutora knows how to help. By using their business intelligence suite, you'll find out which parts of your software provide the most value. Once you know that, figuring out which items you'll work on is a lot easier.