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. Learn how to improve your PBR.
Backlog refinement is the process of discussing, breaking down, gathering details, and estimating backlog item. It is usually done in the current sprint, for future backlog items, not those that are part of the sprint backlog. 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.
How to Conduct Product Backlog Refinement
As is common with the Scrum Guide, there is not a lot of detail about PBR.
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.
Though some people treat product backlog refinement as one of the Scrum events, technically it is not. It often does result in a regular meeting, but it doesn’t necessarily have to.
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. They might 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 it 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.
With new teams, we will create the DoR and keep it handy during backlog refinement. The DoR can help the team focus and guide their discussions during the Product Backlog Refinement meeting.
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 on items that are not ready and. The divisions, if they occur, are easily coached by a good Scrum Master or Agile Coach.
#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) about the business process, the system, or the customer need. They 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.
#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 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.
#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. Going back to the original use of “stories” in XP, it can be as simple as a clear request and a set of acceptance criteria or tests. And the acceptance criteria can be a good 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 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.
Those are my tips on improving the backlog refinement process. I’d love to hear your input.