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.

Author: Anthony Mersino, Vitality Chicago, https://vitalitychicago.com/

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.

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.

Conclusion

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.

About the Author

Anthony Mersino is the founder and CEO of Vitality Chicago. Anthony coaches and trains Agile Leaders to help them understand Agile and Scrum and how to create an environment where people come first, productivity is high, and teamwork is effective and enjoyable. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers. This article was originally published on https://vitalitychicago.com/blog/improving-product-backlog-refinement/ and is reproduced with permission of Vitality Chicago.