Re: [scrumdevelopment] Why backlog grooming?
- +1 to all the previous responses...I will only add that all scenarios are possible in the trenches, depending on the project's team or organization's context...
In short, it will be ideal to have the backlog up to date and prepared (and somewhat already prioritized) before the planning meeting if that is what can be done within that project or organization's context.
This being said, I have also seen situations where the team had a backlog that was not really ready or prepared but which the team only had time to work on "just in time" or would only work on when their customer made the request as part of the sprint planning meeting...
All the best,
Agile and Lean Coach, Author of Scrum in Action
On Mon, May 2, 2011 at 1:32 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:+1 to the other responses. I'll try to add a twist with lean thinking.
"Just in time" is the key phrase. What I and others have experienced is that often times, doing detailed grooming(aka "The 'What' part of the Sprint Planning Meeting") is sometimes too late.
Here are a couple of categories of problems that can arise if this grooming is done too late:
1. Any story with significant open issues that cannot be resolved in the Sprint Planning Meeting.
2. A story that the PO thought was size A, turns out to be estimated to be size 3A. Now the PO wants to re-prioritize that story out of the sprint.
3. One or more stories that the PO thought was size 3A, turns about to be estimated at size A. Now the PO doesn't have enough work queued up for the sprint.
4. One or more stories that have external dependencies that the PO didn't realize.
Think about the kind of waste that occurs here -- it can get pretty bad, especially with a "Shu" level team or PO.
So, we don't want to do BDUF or BRUF, but we also don't want to be thrown into a state of panic right as the sprint is starting with multiple open issues and expected work being in an unstable state.
BRUF is too hot. First time presentation at the Sprint Planning is (sometimes) too cold. A few days before the sprint, IME, seems to be "Juuuussstttt right"... aka "Just in Time."
Note: There is support in the Scrum Guide for backlog grooming as an optional "Tip." I've posted the relevant text below my email signature.
I wrote more on the subject here:
The Case for Sprint Preview Meetings
Tips for a Good Sprint Preview Meeting
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
Scrum 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
From: "hankrussell@..." <hankrussell@...>
Sent: Mon, May 2, 2011 5:48:01 AM
Subject: [scrumdevelopment] Why backlog grooming?------------------------------------
I have always been told, from literature and colleagues that it is important that the product backlog is always up to date, meaning:
• It's estimated - at least enough for one sprint.
• It's detailed enough
• It's got small items on top
The recommendation is to work on the backlog in backlog grooming meetings – ideally weekly but at least once per sprint.
My question is: Why is it so important that the backlog is prepared BEFORE the sprint planning meeting? Following the Lean principles it seems to me that it is better to do the slicing and estimation JUST-IN-TIME, meaning jus before or as the first part of the sprint planning meeting, that way:
• You know more about the system/product
• You have the details fresh in mind when sprint planning begins.To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
To Post a message, send it to: scrumdevelopment@...
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
I'm not expecting every member of team to be homogenous but why do you think having "enough" expertise in the fields you describe is unrealistic? I've met more than a couple of guys who can start and finish any story within given expertise areas in reasonable time and quality. Consider those guys working in pairs with others inside a project and in no time that expertise will spread around.
Also we need to consider risks of "not sharing knowledge" besides productivity. Just think about one of our specialists leaving the team, without sharing the knowledge and experience to other team members. How many projects have the luxury to take such a risk?