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?

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

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

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?

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