Today I read an article on various approaches for Product Backlog Grooming meetings. Underlying the write-up there seemed to be some misconceptions about the purpose and goals, the duration, the participants, the approach, and how often and when to hold a Product Backlog Grooming meeting.

Purpose and goals

The Agile Atlas Core Scrum part mentions the Product Backlog Refinement activity. It’s not necessarily a meeting, but up to 10% of the Development Team’s Sprint time might be used on refining the backlog.

The main purpose of refining the backlog lies in rebuilding the product backlog so that adheres to the DEEP criteria: detailed appropriately, estimated, emergent, and properly ordered (originally: prioritized, but I threw in a deliberate renaming based on recent changes in the Scrum guide).

Detailed appropriately means that we have some product backlog items very detailed. These should be at the top of the current ordering, and they surely will be implemented during the next one or two sprints by the team. On the other hand we have some vague ideas about the product in the future. Some folks call these epics, like large user stories, some call the themes. What really matters is that these are too large, too undetailed to fit into one of the next sprints. We surely have to work on them, refine them, before the team will be able to forecast them in a sprint.

In between there is a large variety of details in the product backlog items. Some are very high-level, others are close to being appropriately for the next sprint.

As part of the backlog refinement activity we have to work with the product backlog to be able to fill at least the next sprint with it. That usually means that we would like to detail enough stories for the next three sprints at most. Detailing more would mean to invest much more effort into unsure work in the future – that could be waste, especially when priorities change based on feedback from the market and customers. Preparing fewer items than for the next sprint accompanies the risk that the team at the next sprint planning will be able merely to plan two stories, where five would fit in. Most teams I have seen do well with having a constant pipeline of one to two sprints worth of backlog items “sprintable” in their backlog.

The backlog also should be estimated. That means we need to do estimation on those items we worked on. These two things together, detailing items, and estimating them, is usually what teams do when they speak about the Backlog Grooming meeting. The emergent and ordering parts – not so much.

That said, the main purpose for the Backlog Grooming meeting lies in preparing enough Product Backlog Items for the next Sprint. Depending on your Product Owner’s rendevouz demand with other folks, you may also need to work on some larger stories, estimate them, and prepare them so that the scope for the current release can be communicated.

Duration and frequency

Time-boxing is a way to foster hard-to-make, critical decisions. In Scrum all meetings are time-boxed. That should also yield for the Backlog Grooming meeting.

Given the Development Team can help the Product Owner on the Product Backlog Refinement up to 10% of their time, that means we could schedule a one day long Backlog Grooming meeting with the whole team on a two week sprint length. I wouldn’t do that. It not only would mean that the team cannot work with the Product Backlog during the rest of the sprint. It would also mean that the team is pulled out of their current sprint for a full day.

What I have seen working for most teams is a weekly one hour Backlog Grooming meeting. When the Sprint starts on a Wednesday, for example, I would schedule the grooming meeting for Mondays. As a Coach or ScrumMaster I would also help the Product Owner to prepare the stories for the grooming meeting, and if there is not sufficient input for a full grooming meeting, I would either cancel the meeting, or make it shorter.

The frequency with some offset to the review, retrospective, and planning meetings helps to make sure you can still clarify open questions for the highest priority items before the planning meeting. Otherwise you would have to leave out an unclear item from the current sprint, even though it has the highest priority right now. That’s usually not a desire.

With one hour each week you also help the Development to focus on their current work most of the time. Your mileage might vary, indeed, but I would be worried if you have to use more than two hours every week on grooming your Product Backlog. That either means that the knowledge gap between the business side and your Development Team is too large, or you have too many uncertainties in your current backlog. Oh, of course, it might also mean that you are deeply into team building, and people try to distract with their hidden agendas during this meeting. Regarding the knowledge gap, you should try training some of the team members in the business domain, either on-the-job with end users and domain experts, or merely send them on a course. Regarding the uncertainties, that might mean that you need to bring a subject matter expert on your team to help them, or you need to invest more effort before being able to have an item in a sprint. These issues usually shouldn’t be solved with more grooming, a longer meeting, etc. The grooming demand instead makes you aware of a potential problem that you should tackle differently.

Participants

At least you need someone with a business domain background, one with knowledge about technical limitations, and one who can challenge the thoughts in the room for completeness, or validity. At least this includes the role of the Product Owner, a programer, and a tester. Some teams do well with just these three experts on their team. Other teams find it more useful to include everyone available in it. I usually start with the latter approach, and lower down the number participants when necessary.

Approach

With the purpose mentioned above, the Product Owner takes the first product backlog item that needs to be either estimated or become more detailed, and the team explores ways to do that. Ellen Gottesdiener and Mary Gorman’s Discover to Deliver provide some more details on this. For the estimation part things like planning poker, bucket estimation, or blink estimation come to mind.

For the detailing part, usually that means to break down backlog items by using one of the splitting cheat sheets available, or exploring ways to break a larger item down into several smaller ones by simply talking. Nonetheless you should be aware of strategies like Dimensional Planning for this as well…

The key thing here is that you should not talk through the whole Product Backlog in one hour every week. That will be dragging for everyone involved. Instead, focus on the most immediate priority. That usually is to be able to fill a sprint from the current Product Backlog. With the time-boxing to one or two hours, you might end up being partly through the backlog, and that’s absolutely ok. In the next week you will be getting deeper into with the next stuff.