When does the Product Backlog Grooming happen?

Last post 06:13 am March 6, 2020
by Amit Kumar
13 replies
Author
Messages
07:46 am February 24, 2020

Hello everyone, 

As per my understanding of the topic, Product Backlog Grooming is of two kinds - 

1. User Stories that are going to be part of the Sprint are groomed in the Sprint Planning Meeting. 

2. User Stories, in general, are groomed in the Backlog Grooming meeting. This meeting has no official sanction in the official Scrum Guide and is not a timeboxed event. 

Is my understanding right? If yes, please let me know when this Backlog Grooming meeting should be conducted and for how long. If no, please clarify. 

04:41 pm February 24, 2020

The Scrum guide recommends that Product Backlog Refinement not take more than 10% of the Development Team's capacity, however, can be updated any time by Product Owner at their discretion. (see Product Backlog section) 

The frequency and duration may be different for every team and every product. 

 

 

04:45 pm February 24, 2020

1. User Stories that are going to be part of the Sprint are groomed in the Sprint Planning Meeting

@Amit Kumar, Backlog refinement does not happen during Sprint Planning. That is an anti-pattern. You'd want to refine your backlog as necessary by allocating some capacity during each Sprint, so that by the time you reach the next Sprint Planning, you can just pull the refined items as per the Sprint Goal that is crafted during Sprint Planning.

04:57 pm February 24, 2020

As per my understanding of the topic, Product Backlog Grooming is of two kinds - 

<...>

Is my understanding right?

Why not check your understanding of this matter by reading the Scrum Guide? What assumptions have you made which perhaps ought to be reconsidered?

06:34 pm February 24, 2020

Scrum doesn't have an event (or meeting) for Product Backlog Refinement. It's up to each team to determine exactly how to go about refining Product Backlog Items into a state that is good enough for Sprint Planning. Although many of the teams I've worked with do have a refinement meeting at some point to coordinate the refinement work, much of the refinement happens outside of this meeting between different members of the Scrum Team. However, you may see refinement elevated to an event status or have a specific meeting in scaled Scrum frameworks such as LeSS and Nexus due to complexities when multiple teams are coordinating on a single product with a single Product Backlog.

The amount of time allocated to Product Backlog Refinement isn't timeboxed, but the Scrum Guide does say that it "consumes no more than 10% of the capacity of the Development Team". As a Scrum Master, I would look at trends. About how long is the team spending in recent Sprints on refinement? How effective is the team at forecasting work during Sprint Planning or how close are forecasts to reality? How long does it take for the team to complete an effective Sprint Planning session? Answering these questions can shed some light onto how effective the team's Product Backlog Refinement is, but there may be other factors at play as well. If the team is consistently, for several Sprints, spending far less or far more than 10% of their capacity on refinement activities, that may trigger me to ask questions and learn more about what's going on to see if there are any problems that need to be addressed.

In an ideal state, the top of the Product Backlog is already well-refined and this is ready for selection in a Sprint Planning. However, this isn't always the case. One of the outcomes of the Sprint Review is a revised Product Backlog. Depending on the input from stakeholders, there may be some less refined items at the top of the backlog. Depending on the amount of uncertainty and ambiguity in these items, the Scrum Team can look at them in Sprint Planning and attempt to refine them. Items that are more uncertain or ambiguous may need to be refined before they can be worked on, but others may be very clear and unambiguous and ready for development with little necessary refinement. Therefore, I wouldn't go so far as to say that refinement at Sprint Planning is an anti-pattern - it depends on why and how much refinement is happening at Sprint Planning.

06:46 am February 25, 2020

Hi Steve Matthew,

 

Thank you for responding. Let me rephrase whatever I've written - In the Sprint Planning meeting, the Product Owner gives a briefing to the rest of the Scrum Team on the User Stories that he believes should be part of the next Sprint. Ultimately, the development team decides which User Stories  make it to the Sprint. In this discussion -

a. Some additional details to the User Stories could be added or some detail that the team feels is now irrelevant could be deleted.

b. The priorities of the User Stories might change.

c. The development team might want to re estimate a few User Stories.

Isn't this Backlog Grooming? In an ideal scenario, the development team may completely agree with the existing structure of the User Stories and hence backlog grooming would not take place

 

Source: I've purchased a course (highest rated) on Scrum from Udemy 

06:52 am February 25, 2020

Why not check your understanding of this matter by reading the Scrum Guide?

 

Hello Ian Mitchell, 

The Scrum Guide does mention that Backlog Grooming should take place but it doesn't mention how and when. Hence the confusion. 

06:56 am February 25, 2020

 Therefore, I wouldn't go so far as to say that refinement at Sprint Planning is an anti-pattern - it depends on why and how much refinement is happening at Sprint Planning.

 

The Udemy course that I've mentioned in the previous post strongly suggests that the Backlog Refinement scheduled during the Sprint Planning meeting be moved to a meeting in the Sprint Pre Planning phase so that the Sprint Planning meeting is smooth and finishes on time. I've seen a number of online Scrum blogs suggest the same.

05:20 pm February 25, 2020

@Amit, the term grooming is offensive in some languages and was changed several versions ago in the Scrum Guide to Refinement.

08:49 pm February 25, 2020

Source: I've purchased a course (highest rated) on Scrum from Udemy

Amit, this is just my opinion, but I'd be skeptical of any Scrum course that claims to be a best-seller and costs only $13.   A quick glance at the course highlighted several glaring errors in their understanding of Scrum (bold = error):

  • In Sprint Planning, items are selected from the Release Backlog (should be Product Backlog)
  • In Sprint Planning, it tells you to break items into sub-tasks, estimate the items in either "complexity points" or "ideal days", and sub-tasks in hours (Scrum makes no such prescription)
  • During a sprint, you can not change items in the Sprint Backlog (you most certainly can)
  • Sprint aim is to complete all tasks identified in Sprint Planning (sprint objective is to meet the Sprint Goal)

I would highly advise against taking this course, Amit.   Everything you need to know is in the Scrum Guide.

10:48 am February 28, 2020

Hello Timothy Baffa, 

 

As a complete novice to Scrum, I think the Udemy course did a pretty good job in getting me acquainted with the basics and terminologies of Scrum. I will take your advice and compare the Scrum Guide against the Udemy course to see how divergent they're with respect to each other. Thank you.  

07:57 pm February 28, 2020

Please keep in mind that the Scrum Guide is the "Source of Truth". Anything else is an opinion without standing meaning trust the Scrum Guide and be skeptical of everything else.

11:56 am February 29, 2020

In my opinion you should be right if we look at scrum's continuous reference to the word `adapt` . In practice, I have seen meetings for backlog grooming (refining) occurring before sprint planning and towards the end of a sprint.

06:13 am March 6, 2020

In practice, I have seen meetings for backlog grooming (refining) occurring before sprint planning and towards the end of a sprint.

 

Conducting the Backlog Grooming session 2-3 days before the end of the current Sprint seems to be the most widely adopted practice. A lot of experienced folks seem to recommend this approach.