Seann Hicks Portrait

Seann Hicks

Agile Scientist and Software Developer

Backlog Grooming

Backlog Grooming is one of a Agile Product Owner's key ceremonies. Here are some tips from my experience to make it successful.

Seann Hicks

5-Minute Read

Banner Image

Photo by Charl Durand on Unsplash

What is Backlog Grooming

Agile practices have a lot of strange names for the roles and activities they encourage. I believe Ken Schwaber felt that this terminolgy helped show that the Agile way was different. I’ve also heard the term ‘Story Time’ and ‘Backlog Refinement’ used to reference Backlog Grooming.

Backlog Grooming is recurring work to keep a Product Backlog (The list of prioritized business requirements) up to date. Everything needs maintenance and attention otherwise it starts to get stale. Project requirements need to be examined, validated and refined continuously. This happens in a waterfall project through change management. Backlog grooming is similar to change management but embraces change as a positive for the project.

Backlog Grooming Objectives

Agile projects typically start the build and delivery to customer activities before the requirements are fully understood or even realized. There is a great deal of activity overlap in an Agile project with the following all happening at once

  • Requirements Analysis
  • Solution Design
  • Build
  • Testing
  • Deployment to Production

All this work might be happening in parallel, but there is still a workflow to follow, where testing happens after build and design happens once requirements are understood. The purpose of backlog grooming is to stay ahead of the design work. In Scrum, work is delivered through all of the above activities in sprints. A small number of requirements are selected in Sprint planning and the design, build, testing and deployment of those requirements occur within the sprint timebox.

Design, build and testing are happening continuously through an agile project, as is requirements analyis. With each one just ahead of the next on a per requirement basis. Backlog Grooming is the name of the requirements analysis work and its objective is to ensure the requirements are far enough ahead of the design and build so that requirements decisions and specifications do not block the implementation work.

Backlog Grooming Schedule Diagram

Typical Activities

Regular, recurring meetings with the project stakeholders, customers, and delivery team are a great way to keep the backlog up to date. A Product Owner has the duty to drive the backlog grooming activities. This can be delegated of course, but I think it is best if it isn’t.

  • Story writing sessions
  • Planning Poker (Estimation)
  • Weekly Grooming Meeting
  • User usage and feedback analysis
  • Product performance reporting

Story Writing Sessions

Story writing sessions is focus time for the Product Owner. If there is a Business Analyst and Quality Assurance team members they should be brought into this activity. Brainstorming and User Story writing happen in this session, questions are likely to surface. Decisions and assumptions are made and possibly documented. The purpose of these sessions is to prepare proposed requirements that can be taken to the grooming meeting.

Planning Poker

Once the next set of requirements is well specified, an estimation session with the delivery team is needed. It helps to have some measure of effort attached to a requirement before prioritizing. Business priority is a cost benefit decision. I won’t go too much into the mechanics of Planning Poker, but essentially, it is a meeting with the team to determine the effort required to complete a requirement - end to end. Because an estimate is required from the team, there is great focus on understanding the true scope of the requirement. The Product Owner or Scrum Master can lead this meeting, and new questions, decisions and possibly new user stories will likely come out of it.

Weekly Grooming Meeting

This is an oppotunity to engage the stakeholders and share the Product Backlog with a focus on the upcoming work. I use this meeting to create alignment on the requirements and priorities. I have used various prioritization techniques. Giving stakeholders a bank of votes that they can apply to requirements helps identify the high value items and create consensus.

Say a stakeholder get 10 votes. They could apply all 10 votes to a single requirement if they feel it is that important, or spread their votes across multiple requirements.

Don’t Overgroom

The power of agile is its focus on business value. Optimizing business value means doing only what is absolutely necessary to deliver that value. Ensuring that a product backlog has every wishlist item and that everything has been fully decided and specified up front leads to wasted and lower overall business value. Low priority requirements that may not be needed for several sprints or may even get cut from scope should get very little attention.

To borrow from lean thinking, we want to deliver as close to just in time as we can.

User Usage and Feedback

I highly recommend incorporating some kind of usage metrics into a product or solution. Metrics provide hard data about how a product is being used. This data is great for determining if a feature is achieving a desired goal. Features that aren’t performing will need adjustment, or to be removed completely. This is a great source of requirements.

Metrics might be difficult in some cases, so I like to use surveys here. Surveys are a good way to guide future requirements and can also be used effectively along with metrics. For example, our product may have a search feature that the metrics indicate isn’t getting much use. Our survey can ask users about the search and give some guidance as to why it isn’t being used. These are 2 great tools to help drive requirements.

Product Performance Reports

Is the product achieving its goals? Is it selling, is the market responding well to it? Metrics and surveys are great but business goals are the bottom line. Requirements related to achieving business goals are necessary too.

If our product is a web site, is it converting customers? Does it get high quality traffic and is it cost effective to run? These considerations should underlie all the requirements in the backog. I use a technique called impact mapping to trace requirements back to business goals.


Backlog Grooming is the Agile term for keeping the project requirements up to date with new ideas from stakeholders, feedback from customers, market drivers and overall business goals. In Scrum, the project requirements are captured in the Product Backlog, and should be at least one or ideally couple of sprints ahead.

Take a look at my posts on Impact Mapping and User Story Mapping as these techniques can help create and refine a backlog.

Recent posts



I believe Agile Iteration is about validating assumptions and optimizing to meet business goals.