The Scrum Guide defines Product Backlog Refinement as the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.
Product Backlog Refinement is a key activity in Scrum that is often overlooked. If a team finds itself regularly reaching the end of the Sprint without completing what they planned and keep rolling things over to the next Sprint, then one of the reasons is likely because the team is not spending enough time on Product Backlog Refinement.
Here are 6 tips for improving Product Backlog Refinement:
- Ensure The Right People Are Participating
Product Backlog refinement is not an activity a Product Owner does on their own. It is for the entire Scrum team which means it’s a collaborative activity with the Developers. It might also include relevant stakeholders or subject matter experts to provide additional clarification on upcoming Product Backlog Items or user stories. The Product Owner ensures the Product Backlog is ordered properly while the Developers ensure the Product Backlog Items are clearly understood and are properly sized to fit in a Sprint. Avoid having a Product Owner or Business Analysts refine the Product Backlog Items on their own and then hand things over to the rest of the team to build and develop. Always have various skill sets represented in the conversations during PBR and this includes analysis, development, and testing, etc. This avoids misunderstandings and ensures everyone is on the same page in terms of the work ahead. Remember, there should be no major surprises in Sprint planning as most items being planned should already be familiar to the team via the ongoing conversations that happened during the refinement activities.
2. Allocate Appropriate Time
Product Backlog Refinement is not one of Scrum’s timeboxed events. Instead, it is an ongoing activity done throughout the Sprint just like the activity of building the Product Increment. So, when planning the Sprint, Developers must allocate enough time in the upcoming Sprint for Product Backlog Refinement. The amount of time allocated will depend on the state of the Product Backlog. In the early days, Developers will likely need to dedicate a lot of time for refinement. As the Product Backlog takes shape, it will have fine grained items towards the top (not more than a 1 or 2 Sprints worth) and more coarse-grained items towards the middle and bottom. At this point, Developers can dedicate less and less time to refinement. The amount of time will never go down to 0 but will likely settle around 10% to 15% to maintain the Product Backlog in this shape and regularly prep for the next Sprint.
3. Progressively Elaborate
A Product Backlog Item or user story is progressively elaborated on as it moves up the Product Backlog. Avoid the trap of discussing and refining an item once and that is it. Instead, refine it just-in-time again and again as needed with more details as more is discovered. A Product Backlog Item might start with just a title. As it moves up the Product Backlog, we might consider addressing who benefits from the feature, what do they need, and why do they need it and write it as a user story. As the user story moves further up the Product Backlog, we might consider adding acceptance criteria to further clarify the user story. As we discover more, we size it and consider splitting it into multiple user stories if it is too large or too complex. Doing all this once, instead of progressively elaborating on them Sprint to Sprint is the same as big upfront requirements. This might lead to waste as we spend time discussing items that end up getting deprioritized or tossed out as more important features get added which in turn increases the cost of change. So remember that refinement is about progressive elaboration.
4. Size & Split
A good rule of thumb to follow for sizing is that no user story should be larger than half the duration of the Sprint. And that is the exception, not the rule. For example, in a two week Sprint, no user story should take longer than a week to complete, and most should be between half a day to 3 days. Following this recommendation ensures we don’t reach then end of the Sprint with nothing to deliver.
A lot of teams struggle with properly sizing and breaking up their user stories into small vertical slices of end to end functionality. Follow patterns for Spitting User stories to help you get better at this.
5. Create a Definition of Ready
A definition of ready can be helpful if it is used as a guideline and not as another gate separating requirements from development. The team creates a definition of “ready” to help set a common understanding on the type of refinement needed for a user story before taking it on in a Sprint. This can include guidance on value, size, acceptance criteria, supporting documents or diagrams, etc. The key here is to use it as a driver for the refinement conversation and not as a gate check.
6. Address What Has Changed
Make sure to discuss any updates to the Product Backlog in terms of what was added, what was removed, what was re-order, and what was learned. This ensures that everyone is on the same page in terms of what is coming up next and the general direction we are heading in based on the Product Goals, roadmap, and feedback. Estimate anything new to assess potential risks and identify possible spikes to run in the next Sprint to increase learning and mitigate the risks.
To help you with product backlog refinement, use the Product Backlog Refinement Canvas. Besides providing a team name and date, the canvas is broken down into 5 sections that guide you through the conversation. Start by discussing what new PBIs got added and why, then move on to discuss what PBIs moved up the product backlog that we need to be aware of and pay attention to, then mention the PBIs that moved down or got removed so we do don’t consider them anymore. From there, we can take a look at the top of the product backlog and address any remaining PBIs that still require refinement, clarification, splitting, and estimation? And finally identify and discuss any PBIs that are risky or complex and might require a spike to get added to the next Sprint’s Backlog to run a short timeboxed research activity to increase our learnings, reduce the complexity and mitigate the risks and prep the item as it gets ready to be taken on in future sprints.
Try these tips to make your Product Backlog Refinement sessions more effective and remember that user stories are all about the conversation between business users or the product owner and developers or the people building the product. And it’s in this sessions that most of these conversations are happening.
