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

Why backlog grooming?

Expand Messages
  • hankrussell@ymail.com
    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
    Message 1 of 60 , May 2, 2011
    • 0 Attachment
      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.
    • 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
      • 0 Attachment
        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.