Backlog Grooming (Ceremony)

Avi Siegel

•

7 min read

What is Backlog Grooming?

Backlog Grooming is a recurring ceremony used on Agile teams where the product manager (PM), engineering manager (EM), and development team review and update items in the product backlog. The process ensures that the backlog remains up-to-date, well-prioritized, and ready for upcoming sprints.

The meeting is also sometimes referred to as Backlog Refinement or Story Time. Backlog Refinement has become the preferred terminology for many due to the negative connotations associated with the word “grooming”. The original intent with using “grooming” was to evoke the concept of tending to a garden.

Note that the Backlog Grooming (uppercase) ceremony is different from the backlog grooming (lowercase) activity. The activity is separately performed by the product manager to ensure the backlog only contains tasks that need to eventually be discussed with the team.

What are the goals of Backlog Grooming?

The primary goals of Backlog Grooming are to:

Have enough tasks ready to pull into the next sprint (during Sprint Planning) to completely fill it up with work for the entire team
Give the team knowledge as to what work is upcoming in the near future, and ensure that work is well understood by the team
Provide room for debate regarding priority, sequencing, and scope of tasks

Pro Tip: Ideally you will be multiple sprints ahead with groomed tasks, for your own sanity and to reduce pressure and anxiety. However, note that (especially with regards to epics), if you review tasks too far in advance of them being pulled into a sprint, the team may forget details, thus necessitating repeat review of the task details.

What is involved in the Backlog Grooming ceremony?

Backlog Grooming is a typically 1-2 hour meeting during which the PM will present each backlog item, starting from the top of the backlog (and skipping over any items which have already been refined). For each item, the below activities will be performed as a team.

Review & refine

Discuss all relevant details about each task, including (but not limited to):

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. The goal is to make it so any engineer who picks up the task has enough information to complete it.

Pro Tip: It is not necessary for every engineer to have enough information to be able to pick up a task. Rather, it is necessary for any engineer who picks up a task to have enough information to complete it. Engineers are not fungible; they have unique skills. Embrace this reality so that you aren’t forced to spend too much time getting people to understand a given task that they will never touch. High-level understanding is good for context; deep understanding is only necessary for engineers that may execute the work.

Break down large sets of work

For any task that can be broken down into smaller sets of work, split the task into more bite-sized chunks, and review and refine as necessary.

Pro Tip: This is the time to break down tasks, not epics. Epics should be broken down into tasks in a separate epic breakdown session.

The exact size of "too big" will be dependent on your team, but a general rule of thumb is that work should fit cleanly into a single sprint, preferably within a single week, and ideally in under a couple days. Of course, that is not always possible, just a target to shoot for.

Pro Tip: The smaller the task estimate, the more confidence there is in completing the work within the expected amount of time. If you can break down your bigger tasks into tiny tasks, you will find you are more likely to reliably finish them quickly. As such, only leave large tasks not-broken-down if it truly makes sense to do so.

Estimate effort

Estimate the amount of effort it will take to complete each task. Note that this is not an estimate of time, it is an estimate of effort combined with confidence. See task estimation for more details on this activity.

Pro Tip: With rare exception, no matter what you do, some amount of time will inevitably be assumed to align with a given estimate of effort, depending on which engineer is doing the work. In fact, it can be easier for some people to estimate by thinking about how long it would take them to complete the work. For the purposes of Backlog Grooming, this is okay. Again, see task estimation for more details.

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.

Note that in the formal Backlog Grooming ceremony, it is most important to get thoughts from the team specifically on sequencing of work within epics, and also the priority of technical work (e.g., infrastructure tasks). The prioritization of epics compared to each other, as well as bugs, support requests, and other non-technical tasks, is at the discretion of the product manager, and can thus be handled outside of Backlog Grooming.

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.

Who should attend Backlog Grooming?

You should aim to keep this meeting small, in the interest of navigating through the conversation efficiently. The only attendees should be the members of the product and engineering teams who need to be familiar with the work. It is the responsibility of the PM to speak on behalf of all other stakeholders (both internal and external).

The following individuals should be invited to Backlog Grooming:

Product manager (to lead the meeting)
Engineering manager (to provide technical context as necessary)
Engineering team (to collaborate on step-by-step grooming of tasks)

Pro Tip: Do not invite individuals outside the product and engineering teams directly involved with the discussed work. That means no customer success, no support reps, no designers, no other product managers or engineers, no sales, no product marketers, etc. It is the responsibility of the PM to know the details regarding tasks that originated outside of the team (and if they don’t know the answers, it is their responsibility to find out, outside of the Backlog Grooming ceremony). If individuals are invited from these other teams, inevitably debates about priorities and solutions end up monopolizing the meeting.

How should the team prepare for Backlog Grooming?

All invitees should be familiar with all tasks to be discussed during Backlog Grooming. The bar is higher for the PM in particular, who should be intimately familiar with all the relevant details, as well as for the EM, who is responsible for being able to speak to technical details wherever necessary.

Beyond the above note, each role should further prepare as detailed below.

Product manager

Before the meeting, the PM must determine which tasks should be on the docket for discussion. To do so, they should revisit strategic priorities for epic-level work, as well as relative priorities of smaller tasks. They should provide the final list to the rest of the team in advance of the meeting, so everyone else can prepare themselves.

In addition to the tasks themselves, the PM will need to be familiar with relevant epics more broadly. This will ensure that, if necessary, the higher level context and plans can be discussed, so that the lower level tasks can be clarified and better understood.

Engineering manager

The EM should be prepared to present and discuss any high priority infrastructure tasks (they will generally lead conversation on these, as opposed to the PM). They should inform the PM of these beforehand, so they can be included in the list of tasks for the engineering team to pre-read.

Engineering team

Engineers should be informed of all tasks which the PM and EM plan to discuss. They should at minimum skim these tasks and form any questions they might have beforehand, so that discussion during Backlog Grooming can be expedited.

Pro Tip: It is highly likely that not everyone will have sufficiently parsed all tasks before Backlog Grooming. As such, it will still be necessary for the product manager to ensure everyone has all the context they need throughout the meeting. Still, it is beneficial to give the team the opportunity to come prepared - that will still help the meeting run more smoothly.

Best practices for Backlog Grooming

Pass off presentation responsibility for a given task to whoever knows it best. If it’s a bug logged by the PM, let them walk through it. If it’s a highly technical infrastructure task which a certain engineer logged, let them walk through it.
Keep the conversation moving. You have a limited amount of time to run through as many backlog items as possible. While having a formal timebox can easily become overly restrictive, keep an eye on the clock, and institute a mid-conversation timebox for a given task if debate is running long (e.g., “let’s give ourselves just 2 more minutes to close this out; if it will take more time, we can work out the details with a smaller group separately”)
Perfect is the enemy of good (and efficiency). While it is important to ensure the necessary details are present within each task, do not spend too much time perfecting those details. It is easy to get carried away with minutiae, and end up having not enough time in the meeting to cover all tasks. If necessary, delegate to someone to correct the details, and re-review later.
The backlog is meant for work. Insights, feedback, feature requests, and ideas do not belong in the backlog. It is the responsibility of the product manager to ensure such items live somewhere else.
Everyone needs to pay attention during Backlog Grooming. This isn’t a time to attempt to multitask and accomplish other work. That will result in having to reiterate information repeatedly throughout the ceremony, as well as missed insights when the knowledgeable party wasn’t paying enough attention to speak up.