What Happens in a Product Refinement Session
The Product Backlog Refinement session is not an official Scrum event, but it is a crucial activity that helps Scrum teams to achieve a shared understanding of the product backlog items in preparation for the sprint planning. Teams that adopt the product backlog refinement as a complimentary practice tend to have smoother sprint planning events. The number of refinement sessions within a sprint depends on various factors such as the state of the product backlog, the maturity of the product, the Scrum team’s availability and experience.
There are so many ways to facilitates a Product Backlog Refinement session but I present some of the activities I would expect a scrum team to understand in any of these sessions. These are not presented in any particular order:
Break down Product Backlog Items (PBIs):
In the Product backlog refinement session, the scrum team should aim to break down PBIs until these PBIs are small enough to fit into the sprint. The definition of done should be used as a guide to discuss the work that needs to completed for every PBI within the sprint. There so many techniques that can be used to break down PBIs but I prefer vertical slicing of PBIs as the scrum team has a higher probability of delivering a usable increment out of a PBI when the PBI is sliced vertically.
Estimate PBIs:
Scrum teams that practice estimation as a complimentary practice, should provide a forecast of effort required to deliver PBIs using the definition of done for the product as a guide. For these teams, estimation of PBIs helps the scrum team select items from the product backlog up to the capacity of the developers. If estimates have already been provided for PBIs, then the facilitator of the Product Backlog Refinement session should re-confirm that every developers remains comfortable with the estimate that have been previously recorded on the PBIs.
Some common techniques for estimation include Story Pointing, T-Shirt Sizing and Planning Poker.
Review Acceptance Criteria:
The acceptance criteria should be reviewed for clarity and completeness in the backlog refinement session. The facilitator should invite attendees of the Product Backlog Refinement Session to ask questions and seek clarification as need. There are instances where the team is unable to agree on the acceptance criteria, especially for a complex PBI; the Scrum team might find it useful to re-examine the ‘why’? The product Owner should be able to clearly express the value of the PBI; my experience is that one the value is transparent to all attendees, the developers can self-manage to figure out the fine details of what needs to be done and how the work would be accomplished.
Discuss Dependencies and Blockers:
It wouldn’t make any sense to pull a story with dependencies and blockers into a sprint as that story will most likely not be completed within the sprint. The Scrum Team should discuss all dependencies and blockers to ensure that everyone has a shared understanding of the dependencies and blockers; the scrum team should put a plan in place resolve these dependencies and blockers. If appropriate, these dependencies and blockers should be represented in the product backlog and assigned to individuals that are working to remove these. As a guide, the scrum team should NOT present any items with unresolved dependencies and blockers for the sprint planning except there is a plan to resolve these impediments within the sprint.
Order the Product Backlog:
The Product Owner is accountable for ordering the product backlog and there are a number of reasons that could be taken in account such Value, Priority, Business Coherence, Technical Coherence e.t.c. The Product Owner should make it a practice to keep the Product Backlog ordered at all times and a session such as the product backlog refinement session is a good time to review and update the order of PBIs in the Product backlog.
As stated in the introduction, the product backlog refinement session isn’t a mandatory Scrum event, however a very useful complimentary practices that helps the scrum team and their stakeholder achieve shared understanding of the product backlog, the product goal contained in it and the product backlog items that have emerged to deliver the product goal.
To learn more about Professional Scrum, join me in one of our scheduled Professional Scrum Product Owner or Professional Scrum Product Backlog Management Skills public classes.
Credit: Photo by Bud Helisson on Unsplash
You Might Also Like
