Backlog Grooming: Who, When and How

Posted by Vikas Hazrati on May 04, 2010

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Best Practices

Backlog grooming, as the name suggests, is giving regular care and attention to a product backlog so that it does not get ugly and unwieldy like an unattended garden with weeds. Though it is not a formal process of Scrum, however, Ken Schwaber recommended reserving five percent of every sprint for this activity. A recent discussion on the Scrum Development group, highlighted the advantages, disadvantages and reservations about the process.

Charles Bradley suggested that for their team, the best time to do backlog grooming was three business days prior to the start of the next sprint and with the entire team. Charles listed the following benefits of backlog grooming

• More time for the new stories to "sink in" before estimating and working.
• More time to optimize design
• More time to research/bone up on requirement hurdles
• Forces the PO to be well prepared for the SPM.
• If the PO discovers something in presenting new stories then he can take corrective action.

Mark responded that he could see multiple problem areas with the approach. According to Mark, this would divert the attention of the team to focus on new work rather than completing the stories in the current sprint. He added that if the entire team is involved in the process of grooming then it might have a toll on the current sprint. Mark reiterated that spending too much time on the grooming session is counter productive and these meetings should not be seen as design meetings. The idea is to have just sufficient detail about the stories so that the planning meeting can be productive.

Likewise, Adam Sroka suggested that though he does not find issues in having another meeting before the planning meeting so that the planning meeting goes well, but a team should not increase the net time on planning. The rule of 4 hours of planning per 2 week sprint should be adhered to. Using grooming as a coverup, teams might want to fix the inefficiencies of their sprint planning meeting, which is not correct.

Responding to the reservations about the grooming sessions, Jim Schiel suggested,

I certainly understand that concern that we're taking people away from coding a few times during the Sprint, but 1) allowing people a little time to turn their thoughts to the future is a good thing -- sometimes, thinking about something different helps them focus more effectively when they return to their tasks and 2) discussing the stories that are coming up is a very effective way to give the team a heads up to problems that will need solving in the next Sprint Planning meeting.

Jim further added that he likes to run the grooming sessions throughout the sprint and not towards the end. He recommended running the session once a week for a few hours.

Ron Jeffries agreed with the idea that spending a few hours in the current sprint for backlog grooming should not affect the developer productivity and in fact should be helpful for the team.

Summarising the direction in which the group was headed, Jussi Menonen added that having a grooming meeting was very helpful in their case.

We have tried to groom and gather the requirements during the sprint planning but it just did not work. We never got enough details out and too often ended up implementing the wrong thing.

Since they were spending too much time in the planning meeting and often implementing wrong behavior they went on the path of having a one hour grooming session in the middle of the sprint.  This seems to be working for them.

Roman Pichler mentioned the strong advantage of having the entire team involved. According to Roman,

Grooming the product backlog collaboratively creates a dialogue within the Scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members coauthor them. This increases the clarity of the requirements, leverages the Scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.

Thus, there is a general consensus that the grooming sessions should be conducted and that the entire team should be involved. Caution is advised against keeping these sessions too long. The suggested time limit is not more than a couple of hours per week.

1. Back to top

   Updates to the discussion and the practice + New articles

   by Chuck .

   (Charles Bradley here, quoted in the article)
   1. Since the above referenced discussions occurred, the Scrum Guide has been updated to explicitly encourage backlog grooming. From the Scrum Guide:
   "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."
   
   2. I've written a couple of articles on backlog grooming with lots and lots more details.
   See www.scrumcrazy.com/tag/view/backlog+grooming

   Reply

• Older >