5 Tips to Improve Product Backlog Refinement

Product Backlog Refinement (PBR) is an activity that many new agile teams struggle with and don’t allocate enough time to complete. Refinement requires an investment of time in the current sprint to get future items ready. This means less time to complete the current sprint backlog items. This article provides some tips on how to improve backlog refinement based on my experience with over 100 agile teams.

Note that in the past, Product Backlog Refinement was called “backlog grooming” though many agile teams moved away from that term due to negative connotations with the term grooming.

Backlog refinement is the process of discussing, breaking down, gathering details, and estimating backlog items. Teams often identify dependencies to completing items and resolve those dependencies. Teams focus on what is needed and why rather than on the specific solution to the business need.

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 essential for Scrum Teams. The refinement 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.

Over the years, I’ve helped a lot of teams to improve their success overall and specifically with product backlog refinement. Here are some of the indications I look for to determine if there is a problem with backlog refinement:

1. Sprint planning meetings take a long time, to the point where the meeting ends without being finished.
2. Teams have a difficult time pulling in work to match their capacity.
3. Items that are completed during the sprint don’t meet the needs of the user or Product Owner.
4. Items are left undone at the end of the sprint and carried over to the next. Carryover negates any type of predictability and makes forecasting impossible.
5. The same items roll over from sprint to sprint, and teams are unsure why.

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 regular meetings that are scheduled throughout each sprint.

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. Just a few meetings each sprint will allow them to refine new items on a regular basis so that items that come into the sprint are ready to be developed.

Some new teams ignore my recommendations because they feel that they already have too many Scrum meetings. Those teams typically struggle to deliver complete backlog items at the end of each sprint.

More mature teams may find that they are able to refine backlog items during their sprint planning timebox. 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. If it works for you, great. My recommendations are meant for newer teams who have not yet mastered refinement. So let’s look at my tips on the PBR process for new teams.

5 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 backlog 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.

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 if they are colocated or in MS Teams if they are distributed. They should keep the 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 to refer to the DoR.

Some people are critical of the use of the Definition of Ready. They worry that the definition of ready fosters 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. 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 struggle 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 struggles 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 hand off 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 of a partner rather than a downstream customer of the requestor.

I also recommend 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 have knowledge of the backlog item being refined.

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: A More Expansive View of Product Backlog Refinement, Stop Estimating in Hours and Story Points – Love them or Leave Them?]

Those are my tips for improving product backlog refinement. 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.