Tips for Effective Backlog Grooming

Posted on June 8, 2011 by charlesbradley

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team’s circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.

Tip #1: Try to never schedule backlog grooming during the first or last 20% of the Sprint.

During the first 20% of the Sprint, the team is just getting started on this Sprint’s work, so you’ll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that’s not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog grooming.

Tip #2: Treat the backlog grooming meeting just like the first part of the Sprint Planning Meeting

Often called “The”What” of the sprint planning meeting, this part of the meeting talks about what will be developed in the upcoming sprint.
- The PO presents the backlog items (often User Stories), the team ask for clarifications, and then the items are estimated by the team.
  - The PO then might indicate that priorities will change based on the estimate. Good! That’s the kind of collaboration that’s supposed to occur!

Tip #3: Make sure the PO knows that, during all of this sprint’s backlog grooming sessions, they will be expected to present enough work to last about 1.25 sprints or so.

The reason for bringing this much work to the meeting is twofold:
1. Often times PBI’s will be de-prioritized based on feedback in the meeting, so you want enough work leftover that you’ll be ready to fill a sprint.
2. It’s a good practice anyway to have a couple of finely groomed PBI’s beyond what you’re working on in a Sprint in case someone frees up and needs more work.

The PO may need to collaborate with the team to know how much work 1.25 Sprints worth is, but it need not be a lengthy discussion — just a very rough guess. Hopefully your team has seen the PBI’s at a Release Planning meeting or in some other backlog grooming discussion meeting. If not, then the PO can discuss the new PBI with a team member or two(informal product backlog grooming) to get a feel for the very rough effort involved.

Tip #4: The backlog items should be fine grained and well understood by the PO for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.

When the PO brings a backlog item to the meeting, what you don’t want to hear is, “Ok, I don’t have a lot of details on this item, but I’ve got the basic gist(or first draft) of it.” What you would rather hear is this “I’ve worked on this item and I have informally collaborated with both the customers and the team on it. I have a really good idea of the details of the backlog item as well as the acceptance tests for the PBI. It’s fairly solid, and I think there’s enough information there to start work almost immediately!”

Even if the initial acceptance tests are high level, that is better than no acceptance tests at all. The more the PO and team focus on getting to good detailed acceptance tests, the better.

Tip#5: Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.

Since the team is getting a preview of the PBI’s, don’t let the team stress out too much on the estimates. Let them know that a PBI’s estimate is not final until the PBI has been accepted into the sprint. If someone comes up with new information between the Sprint Preview and the Sprint Planning Meeting, they are free to bring it up and re-estimate the PBI. This brings us to the converse of this tip.

Tip #6: Make sure everyone understands that priorities are not final until a PBI has been accepted into a sprint.

The PO is free to change the priorities of the backlog between the Sprint Preview and Sprint Planning Meeting. This is ok. We welcome late change, remember? In practice, though, I’ve found big priority changes happen rarely between the backlog grooming and Sprint Planning meeting, maybe 10% of the time or less.

While it may be frustrating for PBI’s to change priority often, remember that this kind of information is something we want sooner rather than later.

Tip #7: Keep your eye on the goals of the meeting

One of the goals of the meeting is that, when it’s over, the team has a handful of PBI’s queued up and ready to roll into a Sprint. All major questions have been answered (or at least assigned to someone to answer), and the team feels confident and knowledgeable about the upcoming work. Of course, like everything, not every last detail will be known, but it’s not for a lack of trying. At the end of the meeting you might try asking this of the team: “Of all of the PBI’s that were presented, a) which ones would make you feel very uncomfortable if you had to start tomorrow?and b) which ones do you not feel confident at all in estimating?” If any of these kinds of risk are identified, assign someone to help mitigate that risk before the upcoming sprint. This brings us to our next tip(available in Part 3 of this blog series — or you can click on the link to the full article below).

Link to Full Article: