Why do Product Backlog Grooming?

Intro

Who likes long meetings? As a Scrum Coach, I ask this question of teams new to Scrum. I ask it mostly in jest, but also as an inoculation against people who will inevitably complain about lengthy Scrum meetings when first implementing Scrum. Obviously I turn it around on them. “I hate long meetings too, why do you think we have such long meetings? What could we do better?” Sprint Planning and Sprint Retrospective meetings can drag on and on and on unless they’re executed well. In addition, the ROI or value of these meetings can be horrible if they are not well structured. In this article, I attempt to make the case that Product Backlog Grooming can greatly enhance the value of your Sprint Planning Meetings, as well as keep them short and sweet.

Some of the best Scrum advice I’ve ever seen/given

One of the best ways I’ve found to greatly increase the value of Sprint Planning Meetings is to do Weekly Team Product Backlog Grooming. Because backlog grooming is not mentioned a lot in the Scrum Guide, and frankly not mentioned a lot anywhere else, teams have to come up with their own way of doing it. Below is my opinion based on my experiences coaching Scrum teams.

edit

What the Scrum Guide Says

(Bold emphasis added by me)

• “Product Backlog item estimates are calculated initially during Release Planning, and thereafter as they are created. During Product Backlog grooming they are reviewed and revised. However, they can be updated at any time.”
• (Optional) “Tip :Teams often spend 10% of each Sprint grooming the product backlog to meet the above definition of the Product Backlog. When groomed to this level of granularity, the Product Backlog items at the top of the Product Backlog (highest priority, greatest value) are decomposed so they fit within one Sprint. They have been analyzed and thought through during the grooming process. When the Sprint Planning meeting occurs, these top priority Product Backlog items are well understood and easily selected.”

(Backlog grooming supplants most of what normally happens in the first part of the Sprint Planning Meeting)

• “The Sprint Planning Meeting consists of two parts. The first part is when what will be done in the Sprint is decided upon.”
• “Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team.”

Some Assumptions of this article

• There are several kinds of Product Backlog Grooming, but in this article, I will focus almost exclusively on Weekly Team Product Backlog Grooming, except as otherwise noted.
• I use Scrum terminology and a 2 week Sprint cycle in this article, but you can translate these concepts to other software approaches and iteration lengths.
• I will use the more generic Product Backlog Item(PBI) term here, except where I make special mention of User Stories. Pretty much everything in this article also applies to User Stories.
• Synonyms for Product Backlog Grooming: backlog grooming, sprint preview meeting, user story grooming, detailing user stories, user story conversations, etc
• Any time I mention “backlog”, “backlog item” or “item” in this article, I’m referring to the Product Backlog and *not* referring to the Sprint Backlog.

What is Product Backlog Grooming?

In my experience, there are essentially three kinds of product backlog grooming.

• Stakeholder Product Backlog Grooming
  • The Product Owner(PO) collaborates and converses with stakeholders to refine requirements for backlog items(usually focusing on ones that will be implemented soon, just in time) and to adjust priorities according to business value.
    • How far the Product Owner gets into detail is team, product, and stakeholder dependent.
    • Often times a PO will bring along a development team member or two to assist.
      • The development team member can provide insight into already existing system logic, as well as relative effort of backlog items, though she should refrain from making estimating comments for backlog items that have not already been estimated by the entire development team.
• Informal Product Backlog Grooming
  • The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their priorities. This should be a daily, if not hourly, occurrence for the Product Owner.
    • When the PO gets together with dev team members, she should strongly consider making sure that the three amigos are there.
• Weekly Team Product Backlog Grooming
  • The Product Owner holds a roughly weekly standing meeting to groom backlog items.
    • Generally speaking, about 90% of this meeting is usually spent grooming the items for the next sprint.

The focus of this article is on Weekly Team Product Backlog Grooming, though I will often just refer to it as “backlog grooming”.

What does Weekly Product Backlog Grooming look like?

The weekly backlog grooming meeting is run just like the first part of any normal Sprint Planning Meeting. The Product Owner presents the backlog items, the team asks questions, and the team estimates them. Sometimes the items need to be split and re-estimated and that’s perfectly ok and even encouraged.

One important note here is that a backlog item is always open for re-estimation until it is accepted into a particular sprint. As such, if some information changes about a backlog item between the backlog grooming and the Sprint Planning Meeting, the team is allowed to re-estimate if they so desire. The same goes for the PO re-prioritizing backlog items between the weekly backlog grooming and the Sprint Planning Meeting. I’ve found this to happen in only about 5% of the cases, so it’s not a big risk. Besides, you’d rather these changes happen a few days *before* the next sprint than a few minutes *into* the next sprint!

Advantages

• More time before the sprint actually starts to:
  • let the new backlog items “sink in” before final estimating and implementation.
  • optimize design, test, etc (i.e. team members pondering the issues in their spare moments for a few days before the sprint begins).
  • explore and resolve external dependencies
  • research/study up on
    • any technology hurdles.
    • any estimate risks like legacy code or code that hasn’t been touched in a while
    • requirement hurdles like requirement holes, ambiguous requirements, validating acceptance tests, etc.
• The grooming forces the Product Owner to be well prepared for the next sprint and helps prevent a “Product Owner Bottleneck,” which is a worst practice.
• If the Product Owner discovers something in presenting new items that inclines them to re-prioritize, they have a couple of days to collaborate with others and get that figured out.
  • The PO can then re-prioritize, queue up new items instead, etc

Disadvantages

• If the Product Owner discovers something in presenting new stories that inclines them to re-prioritize, the team might feel like time was wasted or feel stressed due to the change. While we like front loading risk and knowing these things sooner rather than later, the team may feel a bit frustrated at times. However, that same frustration grows exponentially the longer the change is delayed, so this is definitely a desired disadvantage. It’s a good idea to remind the team that the pain now is smaller than it would be if we found out about it later.
• It can be hard, at first, for some team members to “switch gears” at a time when they’re rockin and rolling on sprint N, to start thinking about sprint N+1.
  • It can take a while to get used to this type of cycle, but all of the teams I worked with liked it much better than a Sprint Planning Meeting that dragged on and on or didn’t provide enough value to the team.

Where do I go from here?

In a future article, I will give tips on how to maximize the effectiveness of your weekly backlog grooming.

Do you have other reasons you like or dislike weekly product backlog grooming?  Post them in the comments.