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!”
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!
It was tedious, and in the end, the Developers didn’t have enough time to plan how to accomplish the work. They had spent too much time deciding what to do in the upcoming Sprint.
A better approach would have been to brainstorm with the Product Owner about what PBIs would add the most value to the Product before the Sprint Planning event. This discussion could have happened at a refinement meeting.
#2 A Product Backlog increases transparency
Remember the Scrum Team that came into the Sprint Planning event without a Product Backlog? Before that Sprint Planning event, stakeholders had yet to learn what the Scrum Team would be working on in the upcoming Sprint because there was no Product Backlog showing what they would work on next. As a result, stakeholders could not set expectations or plan for what they would do once the team delivered the upcoming increment.
A better approach would be for the Product Owner to create and refine a Product Backlog that shows what the Scrum Team will work on next. The team could then review the Product Backlog with stakeholders at each Sprint Review event so that they can see where the work is heading. It’s clear to everyone.
#3 No Product Backlog, no forecast
You can compare the Product Backlog in Scrum to the throughput, velocity or deliverables from previous Sprints to create a forecast, roadmap or other visual representation that provides more information about what the Scrum Team will work on next and possibly when it might be delivered. Without a Product Backlog, it is difficult to create a reliable roadmap because you may have information about where you have been and how long it took to get there, but without a Product Backlog, you don’t know where you are going next.
#4 Refinement can increase higher-value work
When people collaborate during the refinement process, they can sometimes identify higher-value work. When many people share ideas and experiences, they can uncover value that individuals thinking alone wouldn’t come up with. Everyone brings a piece of the puzzle, so to speak, and together a picture of what the most valuable piece of work to deliver next emerges. Collaboration can also result in breaking down the work into more manageable pieces to deliver value sooner.
As a Product Owner myself, I know that when I collaborate with my team and explain what I am trying to accomplish, we can think of better ideas for how to achieve the Product Goal than I would independently. While I remain accountable for the final decision as to the content and order of the Product Backlog, the Developers are the closest to the work and, therefore, may have better ideas on how to achieve the Product Goal.
Rather than trying to come up with everything on the Product Backlog myself, a better approach would be to meet regularly with Developers and stakeholders to request their input on what might add value to the product. The Product Backlog can extend beyond new features. It might include fixes for technical issues as well. For example, if the code is not well organized, it might slow the delivery of new features. In that case, we might add PBIs to the Product Backlog to reorganize or refactor the code. This is just one example of something that could add value to the product by reducing future development time for new features. The Product Owner needs to spend some time ensuring that the product is well positioned for future success not only from a feature standpoint but from a scalability and architectural perspective as well. This may include prioritizing fixes for technical issues alongside new feature development.
# 5 Sizing PBIs is difficult without refinement
Even if the Product Owner decides not to take a lot of input from the Developers for the content and ordering of the Product Backlog, refinement is still necessary because Developers are accountable for sizing PBIs.
Imagine that you are the Product Owner for a house redesign. On your team are two Developers who are accountable for doing the work. Your team is working in one-week Sprints. Now imagine that you create one PBI to demolish and rebuild the house. It’s impossible for two developers alone to accomplish this! I’m sure they’d quit on the spot.
A better approach would be for the Developers to push back and explain that your PBI needs to be broken down further because no one could accomplish it in a single week.
Developers are accountable for sizing the work because they are the ones performing the work. Developers are accountable for delivering a Done increment each Sprint, and they are accountable for the Sprint Backlog, which includes a list of the PBIs selected for the Sprint and a plan for delivering them. They cannot pull work into the Sprint Backlog if it is not sized such that it can be completed within one Sprint. That’s why refining the Product Backlog is critical to the Developer’s accountability. For more on the three accountabilities in Scrum, check out our recent article The Balance of Power.
Conclusion
The Product Backlog is a critical artifact for the Scrum Team and its stakeholders. While the Product Owner is accountable for the content and ordering of the Product Backlog, the best Product Backlogs are created collaboratively, with Developers and Stakeholders providing meaningful input.
The process of adding content, order and detail to PBIs is called refinement. Good refinement can result in a smoother Sprint Planning event, more transparency for stakeholders, a reliable forecast, and the discovery of higher-value work.
To learn more about how to apply Scrum in your unique situation, join us for a day of learning and discussion at next year’s Scrum Day, scheduled for September 14, 2023, in Madison, Wisconsin, brought to you by Rebel Scrum.
