The Five “R”s of Product Backlog Refinement Session

Like many other organizations, some of our teams had struggled to time-box sprint planning sessions. I have observed conversations between delivery members and product owners seeking clarity on user stories, and identifying gaps in the acceptance criteria. As a result, developers were unable to commit to stories, without adding disclaimers – “Need details on the acceptance criteria”, etc. Over time, it became clear that a good backlog grooming session was prerequisite to a great sprint planning session.

Product backlog refinement increases the chance for the team to deliver a successful product. In a nutshell, here are the five activities that describe the backlog grooming session:

Review:  The team looks into the future of an overview of prioritized list of items from a product owner’s perspective. Typically, this helps the team to get an idea of items for the upcoming sprints.

Refine Acceptance Criteria: Product owner typically describes a story with initial acceptance criteria. She/he may not be completely familiar with any constraints or other details that would challenge the acceptance criteria. As the team reviews the stories, they collaborate through open discussions resulting in improving the acceptance criteria.

Re-sizing/sizing: Using story or defect points, items in the product backlog that have been reviewed and refined are sized using one of the estimation techniques (Ex: Planning poker).

Re-prioritize: Based on the feature group or desired outcome of a release, the product owner may re-prioritize items in the backlog based on the team’s input during product refinement session.

Regular cadence: Similar to the other sprint rituals maintain a regular cadence for conducting backlog refinement session. Typically in two-week sprint, our teams would meet for product backlog refinement during middle of the sprint. This gives the product owner at least a week to react to changes requested by the team during the refinement session.