Vitality Chicago Logo

5 Tips to Improve Product Backlog Refinement


The Product Backlog Refinement (PBR) activity is one that many new Scrum teams struggle with. Insufficient PBR often results in long sprint planning meetings and incomplete backlog items at the end of the sprint. This article provides some tips on how to improve backlog refinement, which in the past was called backlog grooming. .

Backlog refinement is the process of discussing, breaking down, gathering details, and estimating backlog item. The focus is on what is needed and why, rather than on how to solve the business need.

Backlog refinement is done in the current sprint, for future backlog items, not for those backlog items that are in the current sprint. Participants in the backlog refinement process include the entire development team, appropriate subject matter experts (SMEs), the product owner or requestor for the item, and possibly the Scrum Master. Others may attend but those are the main actors.

Why Product Backlog Refinement is Important

Product Backlog Refinement or PBR is not only important, but it is also critical for Scrum Teams. The refinement, or grooming as it used to be called, helps align the team on the details of the backlog item. It leverages the insights from all team members to add necessary details to the backlog item. And it should involve a discussion with the product owner, customer or requestor so that the team can gather all the details about the requested item and why it is needed.

Good backlog refinement processes will reduce the risk of items failing the sprint or taking longer than expected. They will expose risk and get all team members aligned with a shared understanding of the business problem.

How to Conduct Product Backlog Refinement

As is common with the Scrum Guide, there is not a lot of detail about Product Backlog Refinement.

Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.

— Scrum Guide (2017)

Though some people treat product backlog refinement as one of the Scrum events, technically it is not one of the 4 events. However, product backlog refinement is often accomplished with a regular meeting.

The Scrum Guide goes on to say that up to 10% of the capacity of the Development Team may be used for backlog refinement.

For new teams, I recommend that they start with a regularly scheduled meeting. I plan for two 90-minute meetings a week. They can adjust the length of the meeting or the number of meetings or simply cancel a planned PBR if they find they don’t need it. Teams might struggle and then learn this themselves from trial and error but I find it more effective to set them up with a few meetings each sprint so that they learn the continual refinement or grooming of the backlog.

More mature teams may find it more effective to refine backlog items during sprint planning. Or they may treat refinement as a continuous flow and leave refinement of the backlog items until mid-sprint when they are ready to develop the backlog item. Whatever works best for the team.

As noted, my focus has been on helping new teams succeed. So let’s look at tips on the PBR process for new teams.

Tips for an Effective Product Backlog Process

#1 – Use a Definition of Ready

Most people are familiar with the concept of Definition of Done, sometimes abbreviated as DoD. The Definition of Done is a quality standard that represents all the things that a backlog item must meet to be considered “done” by the Scrum Team. You could think of the definition of done as the exit criteria that each item needs to meet at the end of the sprint. Common items on the DoD include developed, tested, user-tested, accepted by the product owner, and documentation complete.

The Definition of Ready, or DoR, is a less popular quality standard. The Definition of Ready represents all the things that a backlog item must meet in order to be “ready” to take into the sprint. The DoR can serve as a checklist for the team to guide their backlog refinement process. It also serves as entry criteria for the sprint.

Common items on the definition of ready include acceptance criteria discussed and understood by the team, user story statement (who, what and why), dependencies cleared, and subject matter expert identified.

I took the photo below at a conference at Florida Blue a few years ago. The items on their definition of ready are typical of what I would use with a new team.

definition of ready for product backlog refinement

With new teams, I coach them to create their definition of ready on a flip chart and then keep it on the wall in their team space. They keep their DoR handy during backlog refinement and use it as a checklist when refining backlog items. The DoR can help the team focus and guide their discussions during the Product Backlog Refinement meeting. Once this becomes part of the team’s muscle memory, they may no longer need the flip chart.

Some people are critical of the use of the Definition of Ready. They worry that the definition of ready fosters the use of a requirements phase or that a Scrum Team may push back to the Product Owner on taking on new items identified at Sprint Review or late in a sprint. The team may use it to reinforce waterfall thinking. I don’t see it as much of an issue and if these types of things occur, they are easy to coach around.

#2 – Get the Right People in the Discussion

The right people, IMHO, is the entire development team. The right people will usually also include a Subject Matter Expert (SME) on the business process, the system, or the customer need. That person might be a user of the application. They might even be the Product Owner. The idea is to have someone there who can speak to why the item is being requested and how the solution fits into the business process.

I find that when teams are struggling with product backlog refinement, it is often because they don’t have the right people in the room. The team lacks knowledge of the business request and struggle to identify acceptance criteria or to break the item down.

#3 – Use Good Facilitation and Timeboxes During PBR

The Product Backlog Refinement is usually conducted as a full team meeting, and that makes it very expensive. (Tip: Avoid having one person on the team conduct the PBR and handoff items to the team.) So, good facilitation is essential to keeping this meeting on track.

The facilitator could be the Scrum Master or the Product Owner, however, I recommend that the Development Team members facilitate their backlog refinement discussions. Why? It helps them to own the process of gathering the details and it makes them more a partner, rather than a downstream customer of the requestor.

I also recommend that the facilitator use a timer for backlog refinement, especially at the beginning. Generally, one backlog item should be “refinable” within 10 minutes. Try it and see. If the item cannot be refined in 10 minutes, it usually means that either the item is too big and needs to be split, or, that you don’t have the right people in the room who are knowledgable about the item.

I teach participants to leverage the ELMO technique during backlog refinement. ELMO is an acronym for “Enough Let’s Move On” and it helps remind people to avoid boiling the ocean or rehashing the same thing over and over. Some teams even find it helpful to bring an Elmo doll to their meetings.

On a related note, a good facilitator will keep the product backlog refinement sessions short (less than 90 minutes) and encourage everyone to stay focused. If people are multitasking or if you have a large team (over 7), your meetings are going to drag on, become unproductive, and the cost may outweigh the benefit. No one enjoys dealing with participants who are focused elsewhere and tuned out or ask you to repeat the question or conversation.

It also helps, if you are recording the results of your discussion in an online tool, to have one person entering information in the tool who is separate from the facilitator. It goes faster. And rotate both roles so that everyone on the team has a chance to experience it and will have empathy for those performing the role.

#4 – Some Pre-Work is Helpful before the Product Backlog Refinement Meeting

I find it helpful to make sure some level of work is done in advance of the PBR discussions with the full team. If a backlog item is just a placeholder sentence, then the team can often spin and spend a lot of time trying to understand what is meant. It is better if the Product Owner or requestor or even a business analyst or team member takes some time to document what the request is all about.

This pre-work need not be extensive, it just needs to capture some basic information about the request so that the actual discussion in PBR goes quicker. Going back to the original use of “stories” in XP, it can be as simple as a clear business need and a set of acceptance criteria or tests. Those initial acceptance criteria serve as a starting point that the team can then expand on during the PBR.

#5 – Estimation Serves as a Test

As part of the backlog process, teams will usually estimate the size of the item. The estimation, if done properly, can serve as a good test for whether or not the team is aligned.

By properly estimated, I mean that each person on the team has had a chance to provide input to the estimation. I recommend relative estimation via planning poker. The team discusses the item and then they each provide their own estimate of the relative size of the item, based on their knowledge of the item relative to other backlog items. If they all agree on the size, they are probably all aligned.

If they disagree on the size, or if there are outliers, this usually reveals differing assumptions about the item. The team should let those with the outlier estimates explain their reasoning and assumptions.

Some teams shortcut this process by having one person estimate. This may speed the estimating process but it undermines group understanding and ownership, and teams don’t get the benefit of the wisdom of the whole group. Resist the temptation to speed up estimating. The discussion is much more important than the final number! In fact, some agile experts advise that you ditch the numbers entirely and certainly don’t use them beyond the team.

[Related post: Stop Estimating in Hours and Story Points – Love them or Leave Them?]

Those are my tips on improving the backlog refinement process. Henrik Kniberg produced a short video on the role of the Product Owner which discussed grooming (the old term for refinement) but provides a great overview of the communication needed between the Product Owner, the Stakeholders and the Development Team.

Agile PM book
Agile PM book

3 Responses

  1. Thanks for this! You mention both “the whole development team” and then something such as “meetings over 7”.
    We have ~40 developers in house. It seems like it wouldn’t be efficient to meet with the entire development team. Would a better approach be to meet with the key team leads of the dev team?

    1. Hi Louise, thank you for visiting the website and adding a comment.

      This blog assumes that you are using Scrum. Are you using Scrum? Most people using Scrum find that all the Scrum events are applied at the team level. Though not an official meeting, this would also apply to backlog refinement.

      I am puzzled about your 40 person development team. Do you treat them as one big group? Do they all attend the Scrum meetings? If so, then that would not be efficient as you mentioned. It is likely be a big waste of time for everyone. Most people find that they need to break a large group like this down into Scrum Teams.

      A Scrum Team is defined as:
      – 1 Product Owner
      – 1 Scrum Master
      – 3 to 9 developers

      It sounds like you have (or could have) multiple Scrum Teams within your 40 developers. Each Scrum team would be focused on their own subset of backlog items and they would review those as a team in backlog refinement.

      I’d be happy to have a call to discuss further with you – just let me know. You can also learn more about Scrum in the Scrum Guide.

      Thanks again for visiting!

  2. That’s a piece of helpful information, thanks for sharing.
    I am very impressed with tip #1 you shared above which is to use a definition of ready instead of the definition of done, I also tend to use a definition of done myself, but I realize it seems that definition of ready will help us to be more productive because we can get a clear understanding of the story’s cause, understand the context of the story so that we could better guide how to deal better with this problem. It’s interesting, I will learn how to apply this tip to work. Many thanks to you.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Get More Done Faster

Join 12,000 other Agile practitioners and leaders who receive our monthly Agile and Lean insights to help them achieve competitiveness, productivity and business agility. Go faster!