In a previous article, I discuss the answer to the question of Why do Product Backlog Grooming?. In this article, I discuss some tips for how to do effective backlog grooming. The primary benefits of backlog grooming are increased productivity and increased understanding/quality. Backlog grooming can be a little difficult at first when getting started, but the benefits are large and they appear very quickly, usually after just a couple of Sprints of doing it.
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.
Goals of Weekly Backlog Grooming
- Come out with at least a few backlog items that are finely groomed
- I define “finely groomed” as:
- getting to an estimate that the dev team is moderately comfortable with.
- getting to a deep enough understanding of the backlog item so that the dev team could accept it into a sprint with a moment’s notice.
- Do not over-discuss or over-design.
- splitting the PBI’s where the team feels appropriate — aim for items that are 2-5 person days based on whatever sizing units you use. See User Story Pattern – Micro Stories
- If this is the last weekly grooming session before the next Sprint, then the goal is to have enough high priority items finely groomed to fill one sprint with about 25% extra work also finely groomed.
- The 25% extra is to account for any last minute changes to the backlog (deferring items, removing items, estimate size changes, etc) as well as to have some “on deck” work in case the team needs more work later in the Sprint.
- Get 90+% of details/acceptance tests(aka story tests) discussed, understood, and lightly documented where necessary, preferably as hand written notes on whiteboards (take a picture), cards, or stickies.
- I define “finely groomed” as:
Having met your backlog grooming goals with flying colors, the only thing really remaining to do in the Sprint Planning Meeting is to task out each of the product backlog items and decide which items will be accepted into the sprint. You can also groom any late breaking PBI’s.
Who takes the lead in Product Backlog Grooming?
In short, mostly the Product Owner(PO). While the PO makes decisions about acceptance tests, logic details, and priority of the items, this does not mean it is solely up to the PO to groom the backlog and record details. Who takes on the legwork of the grooming is completely up to the Scrum Team. Said another way, the PO does have the responsibility to make sure the backlog items are groomed, but this doesn’t mean that they have to take on all of the legwork of doing so. Many PO’s do most of the legwork, but this is not a requirement, and will depend on your team situation. Ideally speaking, the “grooming” is a mostly verbal conversation, with only a few important notes or acceptance tests jotted down for each backlog item.
My rule of thumb is the Product Owner will spend roughly:
- 1/3 of their time working with stakeholders to create and groom backlog items for the upcoming few sprints.
- 1/3 of their time leading grooming activities with the development team for items that are in future sprints (focusing ~90% of this time on the *next* sprint).
- 1/3 of their time working with the development team on backlog items that are being implemented during the current sprint.
Link to Full Article:
What your backlog grooming tips? Post them in the comments.