Backlog Refinement: Who Should Attend and How to Maximize Value
This article has an audio version:    Download Audio Version
User Story Examples - Download Now!

I was recently interviewed for an upcoming agile textbook written by Sondra Ashmore and Kristin Runyan, and they asked me some questions about backlog refinement, such as who should attend, how to maximize the value and if the meetings can ever be fun. I’d like to share with you my thoughts on those questions today.

Who Should Attend?

Product backlog refining is not yet an official Scrum meeting. It’s simply something that many have discovered as valuable, and can lead to a more productive sprint-planning meeting.

Last year, I wrote about when backlog refinement might be accepted as a general process in Scrum and the fact that it’s probably still a few years away. 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:

  1. 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.
  2. 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.

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. In the previous section, 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 meetings 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.

Get Your Free Scrum Cheat Sheet

Get Your Free Scrum Cheat Sheet

Sign up below to receive this FREE reference.



Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to