When should Product Backlog Grooming Take Place?

By Roman Pichler, 25th January 2017
Photo by Matthew Henry, courtesy of Unsplash

A well-groomed product backlog facilitates the development of a successful product: It incorporates new insights and learning, and it provides items that are ready to be implemented. But when should you work on the backlog? Before the new sprint starts or afterwards? And how can you decide which option is appropriate? In this post, I discuss four options with their benefits and drawbacks to help you make the right choice.


Option 1: In the Sprint Review Meeting

Your first option is to work on the product backlog in the sprint review meeting. Assuming that the development has developed a “done” product increment and the right people are present, you can use the attendee’s feedback to make the relevant product decisions and update the backlog, as the Scrum Guide suggests and the following picture shows.

This approach ensures that the backlog is updated before the next sprint starts. This allows you to immediately action any new insights thereby mitigating the risk of taking the product in the wrong direction. Additionally, the backlog is collaboratively worked on. This creates strong buy-in from the people participating in the sprint review meeting.

But it only works if the attendees are able to provide relevant feedback, are willing to collaborate and can quickly agree on the necessary backlog changes. What’s more, the feedback must not require further analysis or give rise to bigger backlog changes. Don’t use this option if a significant amount of uncertainty and change is present in your product backlog, for example, if you work on a new product or extend your product’s life cycle.


Option 2: In a Separate Workshop Prior to Sprint Planning

Your second option is to have a separate product backlog workshop prior to the next sprint planning meeting. The workshop should include you as the product owner, the development team, and the ScrumMaster. Collaboratively analysing the data and working on the backlog, mitigates the risk of drawing the wrong conclusions due to cognitive biases; it leverages the creativity and knowledge of the team, increases understanding and buy-in, and leads to better requirements.

As the picture above illustrates, my preference is to hold the workshop right at the beginning of the next sprint. This violates the Scrum rule that the sprint planning meeting must be the first event in every sprint. But it allows you to respond to the feedback in the subsequent sprint without rushing or dropping the sprint retrospective or working late or at the weekend. What’s more, it provides the benefit of separating the data collection from the analysis: It allows you to review the feedback without the people present who provided it. It also give you more time to assess the feedback, derive the right insights, make the right product decisions, and change the product backlog accordingly. This makes it easier to deal with difficult feedback and requests, and to carry out bigger product backlog changes.

Note that this approach still assumes that you can collect the relevant feedback in the sprint review meeting, for instance, by carrying out a product demo, usability test, or solution interview. If you decide to release the product increment to (selected) users, then it is unlikely to work for you, as collecting the relevant data often takes several days in my experience. Take a look at the next option instead.


Option 3: In a Separate Workshop After Sprint Planning

If you validate your product decisions by releasing software to (selected) users, then option three may suit you. It suggests that you hold a product backlog workshop involving the development team and ScrumMaster after the next sprint planning has taken place, as the picture below shows. This approach assumes that you require several days to gather the relevant user data before you can analyse it and make the appropriate backlog changes. It also assumes that you don’t have to wait for the data to arrive to decide on the next sprint goal. Instead, you can continue with the next sprint while collecting the data.

While option three allows you to validate your product quantitatively, it too has a drawback: As sprints are protected, the earliest point in time you can respond to the backlog changes is sprint+2. It is therefore advisable to start with option one and two, and use option three once the crucial risks in the backlog have been addressed. Additionally, you should focus on a different feature in sprint n+1 compared to sprint n in order to avoid the danger of building on wrong decisions.


Option 4: Continuously

If you don’t need to wait until the end of the sprint before you release a new or improved piece of functionality, then option four is for you: You continuously collect data, analyse it, and change the backlog accordingly. You may want to set a side 30 minutes every morning to look at the latest data and draw the right conclusion from it, preferably with the help of the development team or some of its members.

Note that option 4 assumes that you either make small incremental improvements to a product or that you run multiple overlapping experiments to test ideas for new or improved features, for example, by releasing feature fakes or MVFs.

Strictly speaking, Scrum is not well suited to support this approach. The model assumes that a cross-functional development team has to work together for several weeks to achieve a shared sprint goal and deliver a product increment. A sprint is intended to run one experiment or implement related product functionality. It’s not particularly well suited to execute multiple tests and continuously release smaller enhancements and bug fixes. You might therefore consider changing from Scrum to a Kanban-based process, as I discuss in more detail in my post Is Scrum Right for Your Product?.

Summary
When should Product Backlog Grooming Take Place?
Article Name
When should Product Backlog Grooming Take Place?
Description
Find out when it's the right point in time to groom your product backlog: Before or after more development work is carried out.
Author
Pichler Consulting Limited

Learn More

I hope that this article has helped you clarify your understanding when you should work on the product backlog, particularly to validate ideas and translate new insights into backlog items. You can learn more about grooming the product backlog with the following:

Source: http://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/

RSS Feed

Tags related to this post:


6 comments on “When should Product Backlog Grooming Take Place?

  1. 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

    • Roman Pichler

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

  2. 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

    • 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/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?

Leave a Reply

Your email address will not be published. Required fields are marked *