Product backlog refinement—in the past called backlog grooming in reference to keeping the product backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.
I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.
Who Should Attend Product Backlog Refinement?
Product backlog refinement is not an official Scrum event. It is, however, listed in the 2020 Scrum Guide as an activity that should happen during every sprint. As such, there's still no consensus on who should attend.
Although I'm generally a big believer of the whole team’s involvement, that isn't really practical for this meeting. Here’s a couple reasons why:
- Product backlog refinement often happens two to three days before the end of a sprint. There is almost always someone on the team who is frantically busy two or three days before the end of a sprint. If we make that person attend another meeting, we could risk the delivery of whatever product backlog item the person is working on.
- A good rule of thumb is that about 5 to 10 percent of the effort in each sprint should be spent on backlog refinement. While the whole team’s involvement would be nice, not all team members may be able to participate.
What Happens During Product Backlog Refinement?
During a product backlog refinement meeting, the team members and product owner discuss the top items on the product backlog. The team members are given a chance to ask the questions that would normally arise during sprint planning:
- What should we do if the user enters invalid data here?
- Are all users allowed to access this part of the system?
- What happens if…?
Basaed on the answers to these questions, the team might split the story in order to create small enough pieces to fit inside one sprint. A team that does agile estimating with story points will also add estimates to any new or split stories that are bubbling up in priority.
Why Refine the Product Backlog?
By asking questions about upcoming stories earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately if they were asked during sprint planning. If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be necessary to put a high-priority product backlog item aside and not work on it during the sprint.
These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.
Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.
How Do You Maximize the Value?
Maximizing the value of a backlog refinement meeting probably comes down to the same few things for any meeting:
- Keep it as short as possible.
- Show up prepared.
- Encourage everyone to participate.
Remember, conversations about the product backlog are not limited to a certain time or single meeting, so anyone can participate at any time. Earlier, I mentioned that they often happen two to three days before the end of the sprint, but it’s really whatever works for your team.
When you’re refining the backlog, remember that it’s not required that all product backlog items (usually in the form of user stories) are perfectly understood at the beginning of a sprint. The features only need to be sufficiently understood so the team has a reasonably strong chance of completing it during the sprint.
Can Backlog Refining Be Fun?
I have a hard time thinking of any meeting as truly fun, but I do think that when working with the right teammates, meetings can be viewed as welcomed breaks from the more intense work of the team.
Good teams can establish a rhythm where they alternate from very intense mental work either alone or in pairs, punctuated with occasional meetings. The meetings can have a social tone, and be an excuse for joking around with teammates or just taking a mental recess before diving back into the more intense work.
I’ve heard people come up with all sorts of ways to make Scrum events interesting. Most of the ideas I’ve heard are centered on when people are late to the daily scrum (for example, paying a jar, singing in front of teammates or telling a joke), but that doesn’t mean those same creative ideas can’t be inspiration for a less-embarrassing way to keep the refinement meeting light.
Spend a few minutes talking about what you’ve been up to, your family or anything else that makes the meeting seem like less of a daunting task.
In sum, refining the product backlog doesn’t have to happen every sprint, but you should budget time for it to keep small, sprint-sized items at the top of the product backlog so you can defer an investment in items that will be worked on later.
