Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Why backlog grooming?

Expand Messages
  • Andrew Pham
    +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
    Message 1 of 60 , May 2, 2011
      +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@...>
      To: scrumdevelopment@yahoogroups.com
      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 Post a message, send it to:  scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> 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:

    • Seyit Caglar Abbasoglu
      ... 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
      Message 60 of 60 , May 11, 2011
        On the other hand, to be somewhat controversial, I completely disagree that every team-member in a team should be capable of doing all the different pieces of work required to deliver a user story/feature/backlog item. This is not cross-functional, this is homogenous. Expecting a single developer to have expertise in Javascript frameworks, deep knowledge of the relevant business domain algorithms and data structures, expertise in persisting data in data stores, and expertise in messaging and web service technologies needed to interface with external systems, and so on, is simply not realistic. In practise, people will have different strengths and in Scrum it is up to the team to organise its work to make the most effective use of those strengths.

        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.

        IMO neither Javascript Frameworks nor Persisting Data is rocket science (perhaps it was years ago). I've seen a lot more niche knowledge (for example AI programming) could be spread pretty easily as long as team has required specialist at the start and continue to generalize the knowledge.

        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?
      Your message has been successfully submitted and would be delivered to recipients shortly.