I gotta say, refining work items is usually, by far, the Scrum Team’s least popular activity. No one gets up in the morning saying, “I can’t wait to refine the Product Backlog!” (Well, almost no one — shout out to my business analyst friends who actually do look forward to refining the Product Backlog. You know who you are.)
Investing the time to refine work items can seem unnecessary. After all, a Scrum Team can Sprint with nothing in the Product Backlog. In that case, the team’s Developers would collaborate with the Product Owner during Sprint Planning to identify, describe, size and order Product Backlog items (PBIs) they will deliver in the upcoming Sprint. The team would then create a plan for delivering the selected PBIs and work together to craft a Sprint Goal. It’s possible but not ideal. In this article, we will discuss five reasons why refining your Product Backlog is worth the time.
First, what is the Product Backlog?
The Product Backlog is an ordered list of valuable improvements the team will make to the Product. It includes anything the Product Owner believes would add value, such as new features, fixes for technical debt, experiments and more. It is a single source that provides a list of the work the Scrum Team will undertake.
Now, what is Refinement?
Refinement involves adding detail, order and size to your PBIs. You can do it in a meeting or individually. For example, suppose your product is a website that makes pink polo shirts. In this case, a refinement event might be an opportunity for the Product Owner to brainstorm with the Developers about what changes might add value to the product. If the Product Goal is to increase sales, the Product Owner might speak with Developers at a refinement meeting about ways to simplify the website’s checkout process or decrease page load time.
During refinement, the Scrum Team might brainstorm new features or improvements, or they may review the list of upcoming enhancements and ensure that they size each item so they can complete it within a Sprint. Or, the Scrum Team may collaborate with the Product Owner to order the PBIs considering value, size, dependencies and other factors that the Product Owner deems essential. Like so many activities and events in Scrum, the Scrum Guide does not provide details for how to conduct refinement. The guide simply states that during the Sprint, the Product Backlog is refined as needed.
Who participates in refinement?
In short, anyone who is needed participates in refinement. The Product Owner is accountable for the content and order of items, while Developers size them so that they can be completed within a single Sprint. But refinement is not limited to Product Owners and Developers. Stakeholders can also participate at the Product Owner’s discretion. For example, the Product Owner may bring in stakeholders to brainstorm valuable features. Alternatively, the Product Owner might collaborate with security experts to identify features to enhance the user experience. The Product Owner may even bring in other Scrum Teams, customers, or internal and external stakeholders to help determine the most valuable thing to do next.
How often should you refine the Product Backlog?
There's no right or wrong answer to this question. You should engage in refinement as often as you need. Some teams have refinement meetings weekly, some twice per week, and others meet every other week. How frequently a team refines the Product Backlog is context-specific, but it’s not unusual for Developers to spend 10% or more of their capacity carrying out refinement activities.
Why should you refine the Product Backlog?
The Product Backlog is a vital artifact that provides transparency to the Scrum Team and stakeholders about what the Scrum Team will work on next. It might not be a popular activity, but there are five reasons why Product Backlog refinement is worth your time.
#1 A Sprint Planning event without a Product Backlog is tedious. Very tedious.
The longest Sprint Planning event I ever attended had no Product Backlog coming into the Sprint. And it was long. So very long. Imagine an eight-hour Sprint Planning event.
Here’s why that event lives on in my memory as the worst Sprint Planning ever. Because there was no Product Backlog coming into Sprint Planning, the Developers had to collaborate with the Product Owner to create one at the Sprint Planning event. Then, not only were the PBIs discussed and created, but considerable discussion went into how to size each of them. Finally, the Developers devised a plan for delivering the newly created PBIs. The event finally ended after the team crafted a Sprint Goal to describe the purpose of the upcoming Sprint. Whew!