The Product Backlog: Your Product Owner's to-do list

Agile product management is all about creating products and improving them. Software teams know the work is ongoing. As long as there is a product, there will always be improvements to be made! So, in order to keep track of new work — like new features, bug fixes, etc. — Scrum teams use the Product Backlog. The Product Backlog is one of the most important work tools in the Scrum methodology. In this post, you’ll learn what it is, who’s in charge of it, where it fits into the overall Scrum methodology, and how to use it to optimize your team’s performance. We’ll also tackle Product Backlog refinement and the difference between a Sprint Backlog and a Product Backlog.

What is a Product Backlog?

When taking on complex projects and working with multiple people, coordination can feel like half the work. Agile teams know that they need a single point of reference to see what’s on their plate. And that single point of reference is the Product Backlog. You can think of the Product Backlog as a master to-do list, but in reality, there’s a lot more to it. Here are some important characteristics of the Product Backlog:

• Product Backlog items may include new features, bug fixes, technical debt (more on this later), and other initiatives in the form of epics and user stories, though the Scrum Guide doesn’t specify a particular format for Product Backlog items.
• The Product Backlog is a living document, which means it’s always undergoing changes to reflect new information, like changes in the market, feedback from the development team, etc.
• The Product Backlog is an ordered list that starts with high-priority items and ends with low-priority items.
• The Product Backlog also includes important information with each backlog item, such as the acceptance criteria, definition of ready, and estimated story points.
• The Product Backlog is often virtual. This makes it easier to include more context with each item and to conduct Product Backlog management. A virtual board also makes it easier on remote and distributed teams to collaborate. While you can likely find a template spreadsheet, using a software is more user-friendly, especially when it comes to rearranging your Product Backlog.

What is technical debt? 

Have you ever heard the Sheryl Sandberg quote, “Done is better than perfect?” That’s the idea behind technical debt. Sometimes (certainly, not all the time), teams deliberately trade off perfectly-crafted code for speedy delivery. When teams prioritize short-term benefits (speed) over long-term benefits (quality), they recognize they’re accruing something called technical debt, which is the work they’ll have to do later to “fix” what they deliver now. Add technical debt to your Product Backlog to keep track of later work.

Who owns the Product Backlog?

In the Scrum methodology, there are three roles: Scrum Master, Product Owner, and Developers. While all three types of team members can and should contribute to the Product Backlog, the Product Owner is technically responsible for it. They “own” it. 

Owning the Product Backlog means being accountable for managing the list — ensuring that the backlog items are clear, prioritized, and relevant to the overall Product Goal. 

Managing the Product Backlog isn’t a one-time occurrence. Rather, the Product Owner must revisit the process on a regular basis. This process is known as backlog refinement.

Product Backlog refinement

Anyone who works in software will tell you that the work is ongoing. That’s because there’s always room for improvement! And because of the continuous nature of software, there’s always new work coming in, which means new items on the Product Backlog. Over time, your Product Backlog is bound to get a little messy and disorganized.

When that happens, prioritization is non-existent, team members invest their time and energy into the wrong things, and momentum is lost. This is why backlog refinement is a necessary part of product management. 

During backlog refinement, the Product Owner reorders the backlog list according to priority, removes irrelevant items, and adds new items that incorporate feedback from stakeholders, the development team, and customers. Backlog refinement can take place on an as-needed basis, but typically, Product Owners will refine the backlog after a Sprint Retrospective and Sprint Review, before a Sprint Planning Meeting. That’s because it’s best to have the backlog prepared before the next Sprint.

Software teams used to refer to this process as “backlog grooming,” but we prefer to use “backlog refinement.”

Product Backlog vs Sprint Backlog

At this point, you might be wondering what the relationship between the Product Backlog and the Sprint Backlog is. Is the Sprint Backlog really necessary if your team already has a well-prioritized Product Backlog?

Short answer: yes. However, let’s break down the differences between the two artifacts and why both are important for your team’s success.

The Product Backlog gives teams a foundation. It allows them to see their direction, their workload, their goals in more actionable and concrete ways. They might have a Product Roadmap which provides a high-level view of their project, but the Product Backlog expands upon the roadmap with more specifics.

The Product Backlog feeds into the Sprint Backlog. So, the relationship between the two backlogs is that the Sprint Backlog is a subset of the Product Backlog. When it’s time to begin a new sprint, the Product Owner and Developers collaborate to decide which items they’ll pull from the Product Backlog and into the upcoming sprint. The process of laying out the work for an upcoming sprint is called Sprint Planning.

So, why is Sprint Backlog important? What does it offer that the Product Backlog doesn’t? The Sprint Backlog brings more focus. Thanks to the Sprint Backlog, the team is less likely to be preoccupied and overwhelmed with what needs to be accomplished. They don’t need to get caught up with what needs to be done two sprints from now, which drains their focus and productivity. Instead, they can focus on the work in front of them now, the value that they can contribute now. It’s this laser-like focus that allows teams to find their momentum and channel their energy in effective and productive ways. 

In a nutshell, here are the key differences between the Product Backlog and the Sprint Backlog:

‍

The bottom line

The Product Backlog is a collection of work items (namely user stories) aimed at improving a product. When customers, stakeholders, or the development team have a new idea for building upon or improving the functionality of the product, they add that idea to the Product Backlog. Since the Product Backlog is a living document, the Product Owner must continually refine it and reprioritize items, so that it remains relevant and helpful to the Scrum Team.