6 Tips for Improving Product Backlog Refinement

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 it is likely because the team is not spending enough time on product backlog refinement. 

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. 

Here are 6 tips for improving product backlog refinement.

1. 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 from analysis, development, and testing, etc. to avoid misunderstandings and ensure everyone is on the same page in terms of the work ahead. There should be no major surprises in sprint planning as most items being planned should already be familiar to the team via 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 only once. 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 they need, and why 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 at one time instead of progressively elaborating on them sprint to sprint might lead to waste as we spend time discussing items that end up getting deprioritized or tossed out as more important features get added.

Related Article: 5 Must-Haves For Great Scrum Story Writing 

4. Size and 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. Most should be between half a day to 3 days in a 2- week sprint. Consider these 13 Patterns to Split a User Story.

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 that separates 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 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.

Try these tips to make your product backlog refinement sessions more effective. Remember that user stories are all about the conversation; and, it’s in this meeting that most of these conversations are happening. 

======

About the Author

Fadi Stephan is a technology consultant, Certified Scrum Trainer (CST), and agile coach with more than 20 years of experience at startups, government agencies, and Fortune500 companies across various sectors including financial, hospitality, and homeland. His focus is on transforming and building high performing innovative organizations and teams that deliver impactful products early and maximize ROI. Fadi trains and coaches clients on agility and organizational culture, leadership, product management, user-centered design, agile engineering and DevOps. Fadi is based in Washington DC, co-organizes DC’s largest scrum user group, and frequently presents at conferences nationwide.