Skip to main content

Backlog Refinement (Grooming) for Product: Cheat Sheet

Reading: Backlog Refinement (Grooming) for Product: Cheat Sheet

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

  • (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
  • (Optional) representative(s) from the Management Team – clarify the high level priorities
  • (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
  • (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items.  It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

  • Top-order the product backlog to reflect the greatest needs of Management Team and the Product Owner Team
  • Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research
  • Periodically review epics, features or other items on the Management Team roadmap

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when you use Scrum as the delivery framework, product backlog items must be small enough for the team to complete and accept during the sprint. Verify items are implemented to the satisfaction of the Product Owner team. 


Complete backlog items in a single sprint or split them into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

If your team is new to Scrum, ensure the user story format is consistent, meet INVEST criteria, and you write from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service for another team to consume.


Next Feature Integration Sprint: What Scrum teams do during Release Sprint?

Comments (8)

  1. Erik Gibson

    Grooming the product backlog should be a collaborative effort that involves the product owner and the development team. This helps to analyse the data correctly and to draw the right conclusions. It encourages collective ownership, and leverages the creativity of the entire team. It reduces the work load of the product owner, and helps ensure that the high-prirority items are ready .

    • Derek Huether

      Erik, thanks for your addition. To build on your comment, we recommend having a product owner team (not just a single person) to bring clarity to items in the backlog. The product owner team may include architects, among other roles, who may not be part of the individual development teams. This helps ensure items are broken down to the appropriate level for the appropriate team, while still aligning with longer term organizational and design strategies.

      • Patrick Schönfeld

        Not necessarily an argument against your recommendation for a product development team (could imagine contexts where this is justified and works) but I think it is worth noting that this is actually against the Scrum Guidelines, because the Scrum Guide states: “The Product Owner is one person, not a committee. ”

        I think the idea behind it is that is two-fold or rather one depends on the other. For one the product owner is supposed to be responsible for the product value, which (and now we come to the second argument) depends a lot that he or she is actually well-informed about information not only coming from the team but also from external sources (e.g. the market). After all he is responsible to represent ALL stakeholders.

        We all know that shared knowledge / keeping all people informed about everything is in no way easy, which is why Scrum has a lot of events to facilitate communication. If we establish a product owner team, we probably have to add new communication overhead.

        So this is something one should (at least) consider, when following your recommendation.

  2. Clinton Egbemba

    PATRICK SCHÖNFELD i totally agree with you. DEREK HUETHER should kindly explain why he would want to circumvent the scrum guide by recommending a product owner team when the scrum guide is very clear on this subject – “The Product Owner is one person, not a committee. ”

  3. Henk

    Hello, I can’t seem to find the cheat sheet. Where can I download it?

    • Brian Cottmeyer

      Henk, I apologize for any inconvenience. However, after re-reading the post, I believe the post itself may be the cheat sheet? Unfortunately, this particular post was written in 2013 and the author is no longer with the company, so I am unable to verify at this time. I’ll work with our team to determine whether or not we should remove this post to avoid any further confusion. Thanks for checking out our blog, though. I might suggest checking out some of our newer content on our resources page on the Field Notes list page to get our latest thoughts and observations on the Agile industry.

  4. Harold Burton

    Star Fox/Starwing was not only the very first SNES game we ever got, but it was the first ever video game I ever played. And even though it looks dated now, I still enjoy playing it now and again. And I also play Super Mario World too. What? No Super Star Wars, Super The Empire Strikes Back, Super Return of the Jedi, Mario Paint or The Mask? Not even as honourable mentions?


Leave a comment

Your email address will not be published. Required fields are marked *