The following was originally published in Mike Cohn’s monthly newsletter.
Backlog grooming is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery. This activity occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity
Also Known As
Due to the increasingly negative connotation of the word grooming, this activity is increasingly known as backlog refinement or backlog management. Other terms include “Story Time” (see timeline). Grooming was originally used to reflect an organic approach to maintaining the backlog: the intended imagery is that of trimming, pruning, cleaning, as with a plant.
2005: The earliest recorded use of the term “backlog grooming” is from Mike Cohn on the Scrum development mailing list; it will be several years before the practice is described more formally
2008: One of the first formal descriptions of “backlog grooming” is given by Kane Mar, under the name “Story Time”, and recommending it as a regular meeting
2011: The practice of “backlog grooming” is promoted to an “official” element of Scrum with its inclusion in the Scrum Guide
Product Backlog Refinement
sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.
Some of the activities that occur during this refinement of the backlog include:
- Removing user stories that no longer appear relevant
- Creating new user stories in response to newly discovered needs
- Re-assessing the relative priority of stories
- Assigning estimates to stories which have yet to receive one
- Correcting estimates in light of newly discovered information
- Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask the questions that would normally arise during sprint planning:
- What should we do if the user enters invalid data here?
- Are all users allowed to access this part of the system?
- What happens if…?
By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.
If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be necessary to put a high-priority product backlog item aside and not work on it during the sprint.
These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.
Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.
I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.
Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.
If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.
I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and Scrum Master.
The intent of a “Grooming” meeting is to ensure that the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority, and in keeping with current understanding of the project or product and its objectives. Unlike a more formal “requirements document” the backlog is understood as a dynamic body of information. For instance, not all user stories need to have been broken down to a fine-grained level at the onset of the project, or given detailed estimates; but it is important that at any moment a “sufficient” number of stories should be ready for scheduling in the next few iterations. An Agile project is, no less than any other, subject to “scope creep”, in the form of user stories which do not really yield substantial value but were thought “good ideas at the time”, and entered into the backlog lest they be forgotten. In the absence of explicit efforts aimed at managing this inflation, this inflation would result in the too well known pathologies of schedule and budget overruns.