Backlog Grooming: How to Prepare and Run Refinement Meetings in Scrum

The team can adjust the length and frequency of the meeting, or even cancel them altogether, depending on what’s necessary at the moment. The best way to determine how often your team needs Product Backlog Refinements and how long the meetings should last is by gaining experience and making mistakes. Create a graph using all items as nodes and with the dependencies arrows as edges.

This way the Product Backlog Refinement session will proceed in an organized and planned manner. If they disagree on the size, or if there are outliers, this usually reveals differing assumptions about the item. The team should let those with the outlier estimates explain their reasoning and assumptions. I took the photo below at a conference at Florida Blue a few years ago. The items on their definition of ready are typical of what I would use with a new team. The Scrum Guide goes on to say that up to 10% of the capacity of the Development Team may be used for backlog refinement.

Learn & connect

While T-shirt sizing is great for rough estimation of effort, sometimes you need to get a bit more accurate. Using a Sprint Poker or Planning Poker process is a great way to do that. Except this time you’re going to get more precise and reach better story point estimates. This rough estimation method is particularly useful for making sure that items are the right size to enter the Sprint Backlog in the future. T-shirt sizing is a simple estimation technique you may use with your team to get an initial flavour of how large or small a project is.

You could think of the definition of done as the exit criteria that each item needs to meet at the end of the sprint. Common items on the DoD include developed, tested, user-tested, accepted by the product owner, and documentation complete. Smaller, more specific refinements save time for stakeholders and subject-matter experts. Optimize the time of these external people so they never need to discern when, in a three-hour session, their PBI will come up. In this article, we’ll share a few ideas and agile refinement techniques that will help Scrum teams with backlog refinement and involve Developers in requirements development.

User Modeling

You can read in more detail about these and other prioritization techniques in our dedicated article. Scrum, one of the most popular Agile frameworks, suggests building software in iterations, aka Sprints, which last from two to four weeks. As a result of each Sprint, the team releases a product increment.

Finally, the PO seals the deal with the stakeholders updating them of any changes and obtaining their approval. The 2nd items are medium priority items that add to the problem. Splitting user stories to fit the scope of the upcoming Sprint. That way, your team won’t accidentally start a dependent task. Labeling your dependencies also allows your team to prioritize efficiently so that work flows smoothly, and you don’t have to worry about blockers getting in your way. When it comes to your backlog, this means looking at all of the tickets in the backlog and identifying which tickets add the most business value and which are superfluous.

“Celebrity interview” technique used for Product Backlog Grooming

Other companies keep the product backlog, design backlog and bug backlog separate, to maintain clarity. As items get closer to the bottom of the funnel they become more refined and accurate. If ad-hoc discussions are needed to further refine a tricky item, the Product Owner should make time for the team. You want to be in a situation where you have 2-3 sprints-worth of track ready to be laid down at any time.

Scrum Teams use relative sizes because people can determine relations more easily. The first tip is to involve the right members in the session. https://globalcloudteam.com/techniques-and-practices-for-product-backlog/ Product Owner, Scrum Master, development team, QA team, and a few stakeholders are the common participants of the refinement meeting.

Technique Briefs

Small, ready to implement stories though are good candidates for putting a number on them. To help with the latter the Scrum Master can propose additional techniques like Planning Poker and using relative units to limit human deficiencies and reach team consensus on sizing. At the same time, he needs to observe and coach the team to avoid waste by being overly precise with the sizing . A sufficiently estimated Product Backlog helps the Product Owner in prioritisation. They would always prefer low-size (and thus low-risk) PBIs with high value over those with a similar value but bigger size.

• Now that we have discussed the key steps involved in backlog refinement, let’s delve into some best practices that can make the process more efficient and effective.
• As new discoveries are made over time, include them in the backlog or its product risks becoming obsolete.
• Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
• This is a new type of article that we started with the help of AI, and experts are taking it forward by sharing their thoughts directly into each section.
• They also may include or adjust estimates for user stories.
• When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.

While refinement may be one of a team’s most important continuous tasks, the guidance on when and how to do it is very limited. Adding detail helps teams form a better idea of how long a task may take to complete and what resources are needed to complete it. And when estimations are more accurate, it’s easier to plan the correct amount of work for the Sprint and fewer tasks carried over into the next one. As a rule, your product backlog should be closely aligned to your product roadmap. Refinement helps teams shape-up well-sized, detailed and discrete pieces of work that can be tackled in future Sprints.

Keep Customers in Mind

Will we store the credit card information of the customers? How will we keep it, and how will we ensure the security of the stored data? And to build the proper functionality in the right way, we would want to have a clear understanding/answers to these questions and many more that might arise. Product Backlog Refinement is the Scrum Team’s activity to clarify the PBIs to be developed in upcoming sprints.

Without a properly-groomed backlog, the planning session won’t be as productive as it could have been. Although only asking one person may speed up the estimation, that doesn’t demonstrate a shared understanding. And that’s something you should be keen about in backlog https://globalcloudteam.com/ refinement. You shouldn’t refine backlog items currently under development. You should refine the backlog for the next sprint or subsequent sprints. The whole project team has a part to play in this practice, as everyone has different expertise to bring to the table.

Why is Backlog Refinement Worth Doing?

To reach that goal, there are specific user stories that must be completed – often ones that depend on one another in a, well, waterfall pattern. If your team is in a position where there are goals with deadlines, you might choose to put critical path items at the top of your queue. Backlog refinement is not a one-time event but an ongoing process. It should be reviewed and refined regularly to ensure that it remains relevant and effective. By reviewing the backlog on a regular basis, you can identify potential issues early and take corrective action before they become major problems.