My question is rather simple: what is your opinion about running backlog grooming session as introduction to sprint planning meeting and estimate PBIs which are clear to the team. From one side it can save time and allow sprint planning to be more effective but from another point of view grooming for me shall be used to clarify the backlog (split user stories, change priorities, etc.) and make team familiar with upcoming PBIs. Please share your thoughts.
There is no "right" way to conduct your backlog refinement meetings. In fact, you can change it up to get what you need at the time out of it. My goal in backlog refinement is to set the team up to have a successful Sprint Planning. This may involve story splitting, priority discussions, or simple Q&A's. However, I often find that until the team tries to go through the exercise of trying to estimate stories, a lot of important questions may remain hidden.
What I want to avoid is the situation where we get to Sprint planning, we know what is the best work to do, then we find out that we're missing critical information, so we have to push it off until the next sprint.
One way to address this problem is to use a Definition of Ready. Like the Definition of Done, this acts like a checklist for PBI's, only instead of validating that the PBI is complete, if validates that it is ready to be pulled into a sprint. Use backlog grooming sessions to refine your PBI's until they meet your Definition of Ready. Your team can experiment with having estimation in the DoR or not. If you are finding that stories meet the definition of ready but can't be pulled into the Sprint (or cause problems when they are) then you might need a stricter DoR which may include estimation.
A product backlog grooming session can serve several different purposes that like you pointed out generally serve to improve the quality of the items in the Product Backlog. It can also be used to do release planning or generate new stories. In my experience estimating stories during the product backlog grooming session generally has the following advantages:
- The Product Backlog usually contains both Stories and Epics. These together can form themes. This is following the notation of Mike Cohn. In Sprint Planning you would never estimate Epics or whole themes however this is essential for release planning.
- Discussing estimates helps with discovering uncertainties. Especially the widely used method of planning poker where everybody reveals their estimate at the same time makes it very apparent if there are differences in understanding of the scope or effort of a user story. These discussions help to improve the user story (e.g. by changing the wording or breaking it down) or by revealing dependencies (with other stories or even other teams). Furthermore these issues are discovered earlier. If they are discovered during the sprint planning meeting this could mean that a story cannot be planned for the current sprint.
- The sprint planning meeting gets shorter. The focus of the meeting shifts more from the individual stories to possible dependencies and optimal order of implementation.
- The quality of the estimates increases. Estimating can be very exhausting and therefore I made the experience that it’s better to have many short grooming sessions instead of one very long sprint planning. This can (and did in the case of my current team) lead to a more stable velocity and less failed commitments.