When should Product Backlog Grooming Take Place?

Posted on Wednesday 18th April 2012

Summary

Find out when it’s the right point in time to groom your product backlog: Before or after more development work is carried out.

A well-groomed product backlog facilitates the development of a successful product: It incorporates the team’s learning, and provides items that are ready to be implemented. But when should grooming take place? Before the new development work starts or at a later point in time? And how can you decide which option is appropriate for your product? Continue reading to find out the answer.

Option 1: Grooming Takes Place before New Development Starts

Your first option is to groom the product backlog before any new development work starts, as the picture below illustrates. This includes obtaining feedback from users and customers, analysing it, integrating the learning into the backlog, and getting the product backlog ready. (Please see my post “The Product Backlog Grooming Steps” for a more detailed discussion of the grooming activities.)

Grooming takes place before more development occurs

Choose this option if you require feedback from customers and users to decide if and how to take your product forward. Let’s say you develop a new product and you are trying to understand if the solution addresses the user needs selected. It would then be advisable to collect the relevant data, for instance, by demoing the latest product increment or releasing it to the users, to analyse the data, and to integrate your insights into the backlog before you continue developing the software.

Employing this option may mean stopping coding for a few days before the relevant data is obtained and analysed. But this can be preferable over rushing on, only to find out later that the direction taken is wrong, and all the hard work has to be undone.

Option 2: Grooming Takes Place after New Development has Started

Your second option is to continue the development work while you are collecting and analysing the user feedback. The grooming is hence delayed, as the image below shows.

Grooming takes place after more development has started

Choose this option if you do not require the user data to continue developing your product. To put it differently, doing more coding without having first analysed the user feedback does not imply a significant risk of taking your product in the wrong direction.

There are two scenarios when delayed grooming may makes sense: Imagine you develop a new product and you are waiting for user feedback on the latest product increment. Now you want to validate a new, independent assumption, for instance, that you have selected a viable revenue source. So you decide to continue the development before you have analysed the feedback. Similarly, delaying the grooming work may be acceptable if you develop a mature product where swiftly reacting to user feedback is often not as critical.

Summary

Choosing the right point in time to groom your product backlog minimises the risk of developing the wrong product. It may be tempting to delay the grooming work, as it can be easier to write code than talking to target users and customers. But you should only employ this option if you do not require user input to decide how to take your product forward. Have the courage to stop and reflect on the feedback obtained rather than ploughing through your backlog items. To learn more about product backlog grooming, book a place on my Mastering the Product Backlog training course, or get in touch.

  • Pingback: Tips to Grooming the Product Backlog Effectively

  • http://on.fb.me/EarlyAgile Dan Popescu

    Hi Roman,

    It seems to me that the way we understood the term and practiced the grooming technique differs a little from the one presented here…

    In our Agile/Scrum environment we have given a more broader connotation to the Grooming term, one that while still incorporating the user feedback, it somehow shifts the customer centric view by involving the Team(s) into the process and relying heavily on the 2nd C of User Stories, namely conversations.

    Basically, our grooming consists in feature-linked conversations between the Product Owner and the Customers that go along the lines of the the Why and the What, followed by discussions between the PO and the Teams that aim at clearly communicating those two W’s, but those are also followed by a lot of other more technical conversations between the Developers, both intra- and inter- Teams, that dive a little into the yet uncharted territories of the How.
    From our experience we’ve observed that whenever the last type of conversations did not took place, we found ourselves having a really difficult, long and sometimes even frustrating Sprint Planning meeting.

    Considering all these, we actually have only one option, “Option 1: Grooming Takes Place before New Development Starts”, and whenever possible we’re trying to pipeline the grooming during the second part of the ending sprint, and not have it between sprints, as it is presented in the figure above.

    I would be very interested in knowing your thoughts about our grooming process.
    Would it be advisable for us to continue calling as “grooming” the whole preparation that takes places before Sprint Planning?
    Any improvement ideas that you might have for us would be more than welcomed.

    Thanks,
    Dan

    • http://www.romanpichler.com Roman Pichler

      Hi Dan,

      Thanks for sharing your grooming approach. You seem to include technical conversations in step five of my grooming process, which I call “Getting the Stories Ready”: http://www.romanpichler.com/blog/product-backlog/the-product-backlog-grooming-steps/ And that’s perfectly OK in my opinion. I would, however, suggest limiting the conversations to resolving dependencies between teams, and to discuss how the stories are implemented in detail in the planning meeting. If that’s not feasible then the team may lack the relevant knowledge to deliver the stories. Developing spikes or adjusting the team composition can help.

      If you haven’t done so then you may want to minimise any inter-team dependencies, for instance, by preferring feature teams over component teams. The ideal team setup should allow each team to groom their backlog or backlog part largely independently of the other teams (as well as implement and test the software autonomously).

      Does this help?

  • https://www.facebook.com/EarlyAgileEducation Dan Popescu

    Hi Roman,

    You’ve spotted correctly what some of us also believe to be an important improvement point we should make to our current Agile approach, namely adjusting the team composition so that each can attack a whole feature.

    The lack of relevant knowledge is quite often seen, as members of other teams need to be invited during grooming or even during sprint planning, in order to explain some topics or answer questions the developers inside the team cannot answer by themselves…

    Thanks a lot for your answer!
    It really helped.

    All The Best,
    Dan

    • http://www.romanpichler.com Roman Pichler

      Thanks for the feedback. Glad to hear that my suggestions were helpful. All the best for your teams and the product.

  • Pingback: Using the Product Demo as an Agile Market Research Method