A refined 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 product 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 product 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 Scrum product owner, the development team, and the Scrum Master. Collaboratively analysing the data and working on the backlog, mitigates the risk of drawing the wrong conclusions due to cognitive biases like confirmation bias; 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 enables 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 this option is unlikely to be appropriate for you, as it often takes several days to collect the relevant data in my experience.
Option 3: In a Separate Workshop After Sprint Planning
If you validate your product decisions by releasing software to (selected) users, then this option may suit you. It suggests that you hold a product backlog workshop involving the development team and Scrum Master 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 different features in sprint n+1 compared to sprint n in order to avoid the danger of continuing to move your product in the wrong direction.
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 you will benefit from continuously collecting data, analysing it, and changing the product 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 works 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 to 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 article “Is Scrum Right for Your Product?“
Post a Comment or Ask a Question
6 Comments
hi Roman ,
I agree with the 4 options to groom the story . However, what is also relevant is how early in the game we wanna groom. Should we do it when we see the given feature getting a priority in our Roadmap OR should we do it randomly even though the actual implementation is a while away from our roadmap.
I strong believe that we should always do a grooming only when we are confident that the given feature is close enough (along with priority) in the roadmap so as to accommodate as much scope change as possible and ensure the team is in top of any possible technical dependencies that might have come up because of previous implementation.
Thanks for your comment Shashank. I recommend that you refine or groom the product backlog just in time, at least as long as your product is changing. This allows you to leverage the latest insights gained from gathering user feedback and data in order to make the right product decisions. I also have a preference to focus the product backlog on the next major release, as I explain in the article The Product Roadmap and the Product Backlog. Does this help?
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
Thanks for the feedback. Glad to hear that my suggestions were helpful. All the best for your teams and the product.
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
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”: https://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?