Product backlog refinement is a challenging and important test that all Scrum teams need to do on a regular basis. In fact, the Scrum Guide talks about Scrum teams spending up to 10% of their capacity per Sprint on product backlog refinement. But should product backlog refinement be an event, and what are your responsibilities as a Scrum Master when it comes to product backlog refinement? Before we answer those questions, let's just take a quick recap of exactly what product backlog refinement is, and why it's so important. Simply put, product backlog refinement is the process of taking stories in the backlog, and making sure that they're ready to be worked on. To be ready, they need to be clearly explained, and small enough that they can be worked on and completed in a single Sprint. The product owner is primarily responsible for this, along with the development team. However, as a Scrum Master, you can support them by researching techniques for effective product backlog management, helping the Scrum team understand the need for clear and small backlog items, and facilitating Scrum events as needed. And this brings us to if product backlog refinement should be a Scrum event or not. Technically, it isn't one. But the Scrum team as a whole must decide how they want to do product backlog refinement, and therefore they could decide that they want it to be a Scrum event. By being really active when it comes to product backlog refinement, you can make sure that there's always meaningful work lined up to do. Scrum Masters should encourage their product owners to have about a Sprint and a half's worth of work in the backlog at any point. This will future proof them if, for instance, the product owner isn't able to attend the Sprint planning session. And because the whole Scrum team has been engaged with product backlog refinement, they should feel comfortable in pulling in work. Of course they should also know what work has the highest priority. As part of the product backlog refinement, should be to put the most valuable work higher up the list. Again, as a Scrum Master, you need to help your product owner to do this on a continual basis. That isn't to say that it's your responsibility to manage the backlog, it's not, but you can support the product owner by removing impediments, coaching them, and as we mentioned earlier, through researching how other teams are doing effective product backlog management. There are two simple methods you can use to help your product owner improve the product backlog refinement right now. Start off by making sure that your backlog is DEEP. This is a simple acronym you can think about when it comes to the key elements of a well refined backlog. Detailed stories help developers to understand what they need to work on. Stories that are estimated for effort can in prioritizing based on the value they will provide. Product backlogs should be emergent, this means they will change over time. Finally, product backlogs must be prioritized from the least to the most valuable item so that the team always knows what work they should be doing to deliver the most value. Another simple acronym you can remember when it comes to helping your team with their product backlog refinement is INVEST. A little more detail than its DEEP counterpart, INVEST tells us that product backlog items need to be independent of each other, negotiable in terms of their scope, valuable to either the customers or business, estimable for effort, small enough to be completed within a Sprint, and have testable conditions for success. So, that's it for this video. Product backlog refinement is one of the most important ongoing activities for any Scrum team. As a Scrum Master, you need to make sure that everyone understands what their role is here. If they need a specific meeting to do this mid Sprint, don't be afraid to facilitate it. Take the time to coach your product owner and support them with research on current best practice. Lastly, use models like DEEP and INVEST to help your Scrum team create the best possible product backlog.