Cheat Sheet for Backlog Refinement

WRITTEN BY Derek Huether


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:

  • The product backlog is top-ordered 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
  • Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team. 


Backlog items must be completed in a single sprint or split 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

Ensure the user story format is consistent, INVEST criteria is being met, and is written 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, to be consumed by another team.

Image Credit: Pictofigo

Want to get better at refining your backlog?  Check out our training and learn how.


leave a comment

Leave a comment

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


4 comments on “Cheat Sheet for Backlog Refinement”

  1. Cheats Download

    You really make it seem so easy with your presentation but I find this
    matter to be actually something which I think I would never understand.
    It seems too complicated and extremely broad for me.

    I’m looking forward for your next post, I’ll try to get the hang of it!

  2. Derek Huether

    Thanks for the response. Take heart in knowing that the concept of backlog refinement is simple but the execution can sometimes be hard, especially when you’re looking at your backlog from a portfolio or program perspective. That’s why I wrote the cheat sheet. I just wanted people to not forget the basics, before they go jumping in with both feet.

    Keep asking yourself and your team if the work you are about to start is actually “ready” to start. Is it too big? Is it too vague? Is it testable? Do you have explicit acceptance criteria? If you answer NO to any one of these questions, it’s something you need to discuss during this meeting. It’s an opportunity for a few members of the team to get stuff ready to start in the near future. We all know you will waste a lot of time if you start working on something that is not ready. So, take time to get it ready!

  3. 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.

Resources View All
Slideshare Presentations
PMI-ACP Training Deck View
Slideshare Presentations
From Agile2013 – Sustainable Change View