Backlog Grooming (Activity)

Avi Siegel

•

8 min read

What is backlog grooming?

Backlog grooming is a continuous activity performed on Agile teams where the product manager (PM) reviews and updates items on the backlog. This ongoing exercise ensures that the backlog provides a clear view of the priorities of the team, as well as an indication of where attention needs to be focused to fully prepare work for future sprints.

Note that the backlog grooming (lowercase) activity is different from the Backlog Grooming (uppercase) ceremony. The ceremony is a recurring meeting performed with the entire team to ensure that the backlog remains up-to-date, well-prioritized, and ready for upcoming sprints.

What are the goals of backlog grooming?

The primary goals of backlog grooming are to:

  • Provide a clear view of the priorities of the team

  • Efficiently utilize the team’s time in Backlog Grooming and Sprint Planning sessions by having the tasks as refined as possible by the PM before involving others

  • Know which specific tasks are ready to be discussed in the next Backlog Grooming and Sprint Planning ceremonies, and have enough of them to adequately take advantage of the prescheduled time

What is involved in the backlog grooming activity?

Triage

As new tasks are logged in the system, they must be routed and detailed as appropriate. These new tasks should automatically be placed into a triage area, so they can quickly be prioritized.

Note that the purpose of a fast triage process is not to handle the work quickly, it is to determine if the work needs to be handled quickly. If it is indeed urgent, it can be escalated into a sprint or prioritized high in the backlog.

Pro Tip: Apply a triage process to all tasks, not merely bugs and support requests. For example, if an engineer logs a new infrastructure task, it should not automatically be promoted to the backlog; rather, it should first be reviewed by the PM and/or EM to determine if it is work that will actually be performed, and if so how it should be prioritized.

Prioritize & sequence

Reorganize tasks into the approximate order they should be completed in.

  • Generally this should be highest value items at the top, lowest value items at the bottom.

  • Especially in the case of tasks that fall within the same epic, tasks may be required to occur in a given sequence.

Pro Tip: The higher an item is on the backlog, the more important the exact priority order is. That also means that the lower an item is on the backlog, the less important the exact priority is. Do not spend too much time fretting over the exact sequencing of work that is not imminent.

When applicable, tasks should be grouped by epic, especially when prioritizing further down the backlog. While this may not technically match the expected sequencing of work, this has several benefits:

  • It reduces cognitive load when parsing the backlog.

  • It naturally helps avoid commingling epics, which encourages more focused work.

  • It helps not visually lose track of related tasks.

Pro Tip: It may be useful to prioritize different task types separately from one another (in separate, filtered views). E.g., it is often infeasible to provide an exact stack ranking of a medium priority bug vs. a medium priority story of an epic multiple sprints or quarters away. In reality, teams typically try to address a certain amount of bugs per sprint, compared to a certain amount of feature work, compared to a certain amount of infrastructure work, etc., which means that in practice, priorities matter more within task types than between task types.

Review & refine

Especially for tasks towards the top of the backlog, ensure as much detail as possible is provided. This includes such areas as:

  • Context

  • Job stories

  • Core requirements

  • Acceptance criteria

  • Available visuals (screenshots, mocks, etc.)

  • Outstanding questions

Adjust any inaccurate, misleading, or ambiguous statements, and add missing details as necessary. Anywhere you have questions, track those within the task itself, so they can be reviewed together with the team at the appropriate time.

Pro Tip: The goal here is to later save the broader team’s time. If you enter formal Backlog Grooming with incomplete task details that could have been complete, the entire team will have to watch as those details are updated or added. Time is your team’s most precious resource - don’t waste it.

Prepare

Ensure you are prepared to enter Backlog Grooming and Sprint Planning sessions with a plan of which work needs to be reviewed. The goal here is twofold:

  1. To efficiently utilize the team’s time during Backlog Grooming and Sprint Planning

  2. To self-verify that enough work is refined enough to be reviewed in the first place (i.e., that you don’t need to perform more reviewing and refining yourself first)

Pro Tip: Utilize task statuses specific to the backlog to track state of readiness outside of sprints. For example, statuses of “Ready for Grooming” and “Ready for Planning” can help you track which tasks you want to discuss with the team in the respective Backlog Grooming and Sprint Planning ceremonies. Further, starring, favoriting, prioritizing, or utilizing sprint sandboxes can help you track the set of tasks you actively plan on discussing with the team in the relevant ceremonies. This will enable you to show up to the ceremonies prepared to run through a specific list of work.

Archive

It is common for backlogs to, as they continuously grow, slowly but surely become an unruly mass of work, some percentage of which is no longer even necessary to act on anymore. Archive these tasks. For example:

  • If a bug is a year old and has not been reported again, it may have been fixed during other work (or is so rare that it’s not worth the team’s time to fix).

  • If the PM took over the team from another PM, there may be a large set of tasks which are lacking enough context to understand what they were meant to represent.

  • If strategic priorities change annually, there may be work that is no longer on the short term (or even medium term or long term) roadmap.

  • If a support request was entered into the system a year ago, but the customer has since churned, the work no longer needs to be performed.

  • If the company pivoted, there may be feature work that is no longer relevant to the new vision.

  • If a feature was deprecated, supporting tasks will never need to be completed.

  • If code was refactored, related bugs may have indirectly been fixed.

  • If a bug was reported multiple times, only one instance is necessary to keep.

Additionally, there are often tasks that don’t belong in the backlog in the first place. Archive these tasks, and create counterparts in other systems as appropriate. For example:

  • Ideas belong in an idea tracker, not in a backlog (and not in a roadmap either).

  • Feature work is generally prioritized in terms of epics on a roadmap - standalone stories that are not associated with an epic may thus never be prioritized (unless the work is truly tiny effort, consider converting the story into an epic, and prioritizing that epic on the roadmap).

  • Infrastructure work should be discussed with the EM and/or PM either before, or soon after, an engineer creates a related task in the backlog - otherwise the work will realistically never be prioritized, and thus might as well not be cataloged.

For all the reasons above, don’t be afraid to archive tasks that are no longer necessary to track or simply don’t belong.

Pro Tip: While there isn’t a strict rule for how many tasks should exist in your backlog, consider giving yourself a soft cap that makes sense for your team, given how you break down work and how fast you close out tasks. E.g., if you have a thousand tasks in your backlog, and your team generally closes twenty tasks each two-week sprint, then it would take two years to complete all that work if nothing new was ever added to the backlog. All those tasks toward the bottom of your backlog are realistically never going to get done - just archive them. If they’re important, they’ll come up again.

Who should perform backlog grooming?

The activity of continuously grooming the backlog (outside of the formal ceremony) should be strictly performed by the product manager. The core reason for this is that the PM needs to be intimately familiar with all work represented in the backlog, as well as respective priorities. If anyone else starts changing priorities, triaging incoming requests, archiving old tasks, or the like, then work will inevitably get lost in the shuffle.

The one aspect of backlog grooming which other individuals can (and are welcome) to participate in is refinement. It is of course helpful for individuals knowledgeable of the logged work to provide as much detail as they can. This most applies to initial entry and updates as information becomes available (e.g., a customer support agent should revisit a logged bug to add more details about the user’s actions that brought about the issue, engineers should revisit logged infrastructure tasks if they didn’t have time to fill in all details at the time of original entry, etc.), as well as when engineers are preparing for the Backlog Grooming ceremony.

Best practices for backlog grooming

  • Think about your future self. In the same way you don’t want to waste your team’s time in future ceremonies, you don’t want to waste your own time during this grooming exercise. The more organized your backlog is, and the less clutter there is, the more efficient it is to perform later grooming. Consider these future time savings as you groom (especially, e.g., regarding your willingness to archive tasks).

  • Set aside dedicated time each week to keep the backlog as groomed as possible. Even just 30-60 minutes of focus time per week can stop the backlog from becoming a giant mess.

  • Archive work that won’t be done anytime soon. There is often much work that feels like it should, or even must, be done. However, given time and staffing constraints, this work may realistically never be prioritized. Consider the tax of having an ever-growing, infeasible to search through, impossible to scroll through backlog. How many times will you or someone else end up rereading ancient never-to-be-done tasks when looking for a certain other task? How useful is it, really, to have a giant list of work that nobody will ever do? If you can plan 3 years out in your mind, and you still can’t see the team executing against it, then why bother tracking it? Don’t be afraid to archive tasks. Take solace in the fact that, if the work is truly important, it will get logged again.

  • Aim to zero-inbox your product backlog. This does not mean you should have zero items in your backlog, it means you should have zero items in your backlog which require your attention. Non-broken-down epics belong on the roadmap, not the backlog. Unreviewed bugs belong in a triage view, not the backlog. Ideas belong in insight trackers, not the backlog. Unrefined tasks that lack context and details and will never be done anyway minimally belong in the icebox, but really should just be archived. What remains are the tasks that you should prioritize and refine. Stay on top of that shortlist, and you’ll improve your sanity.