Reviewed by: Raúl Herranz
A product backlog is an emergent and ordered list of everything that needs to be completed on the road to developing a product (or service, experience, marketing campaign, etc.). The product backlog is an essential part of the scrum framework and one of the three artifacts, along with the sprint backlog and an increment.
A product backlog is the scrum team's single, ordered list of work to be done for the product. Individual work items that make up the product backlog are referred to as product backlog items, or PBIs.
Rather than a static list, the product backlog is a flexible, evolving tool: It can and should change often, as new information is learned from customers, the marketplace, or stakeholders. Not everything on the product backlog will be worked on. It can be a place to gather ideas until they can be fleshed out further (during refinement activities) or eliminated if no longer valuable.
In the scrum framework, a product backlog is considered one of the three artifacts: something that represents work or value. The product backlog artifact is inherently linked to the product goal as a way to transparently order the work that needs to be done on the path to that goal.
The product owner on the scrum team is accountable for maintaining the product backlog and ensuring that work is ordered and that this order gets the team closer to the product goal. Rather than stakeholders getting to ask team members to work on something for them, they must talk to the scrum team’s product owner.
The product owner's decisions about the content and order of the product backlog (including whether to say "no" to adding new requests to the backlog) should be respected and recognized throughout the organization. The scrum master plays an important role in helping everyone in the organization understand the product owner's accountability for the product backlog.
A product backlog gets refined regularly to add details, and updates, and ensure the relevancy of the product backlog items. Refinement most often takes place in two situations: strategic refinement that takes place whenever the product owner talks with someone else about a new feature, an expected change in the product, or something to remove from the backlog.
The second type of scenario is a tactical refinement in which the scrum team adds more details to PBIs and may split the work into multiple PBIs if the existing items are too large in scope.
Generally, a team refines the items at the top of the list first, working their way down as time allows. Refinement activities ensure that the items at the top of the list are ready for the team to begin working on.
The product owner needs to make sure that work is clearly understood by everyone. However, this doesn’t mean that every little detail needs to be documented. While refinement adds detail, agile teams value collaboration and interaction over documentation and processes; therefore, instead of planning the work down to the smallest to-do item, scrum teams tend to rely on their product owner to understand the desired outcome and then collaborate to determine how they will get to the outcome.
A product backlog in scrum can be a game changer for many companies. There’s value in having work in a single place so both the team and stakeholders have visibility into the work and progress toward the product goal. This transparency and visibility support effective trade-off conversations and focus on the highest-value work.
Because the product backlog is a direct reflection of the product goal, it makes it a lot easier for the product owner to negotiate with a stakeholder or another department when they have requests for the scrum team. The backlog is a readily available, readily comprehensive list of work both parties can look at as they discuss whether a new work request for the team can be brought in.
Also, a product backlog is an essential part of scrum. Without it, scrum cannot be successfully practiced. The backlog is the foundation for the team's ability to work in sprints, focusing on increments of work at a time. It allows for flexible, evolving, just-in-time planning, it supports collaboration and discussion, and it enables the scrum team's ability to focus on a set of high-value items for a defined period of time.
A product backlog can be thought of as an iceberg, with large and ambiguous work towards the bottom, and more defined, ready-to-go work towards the top.
Each product backlog item should be able to deliver value on its own, so you want to think of PBIs more as features or deliverables rather than tasks of a larger project.
Imagine that you are building a new crafting tool. Examples of effective PBIs include:
Avoid PBIs that are stand-alone tasks that don’t deliver customer value. Here are a few bad examples:
While these items above are needed, they can be written as tasks to complete the PBI, but don’t work well on their own because they aren’t delivering anything or providing an increment of the product.
Teams may write their PBIs as user stories. A user story is a way to express the work from a user’s point of view, which can be a valuable way to communicate the work to all team members. Not everything on the backlog needs to be expressed as a user story; it’s perfectly acceptable to mix user stories and non-user stories together. Just do what makes sense for your team to best understand the work.
The key things to remember when writing the product backlog are:
A product backlog is a great tool for ordering work and being transparent about what may get done. It also helps people understand what work won’t get done because it doesn’t align with the larger product goal. If you don’t have a product backlog yet, it’s an easy way to get started with scrum and will bring a lot of clarity and organization to the way you work.
If you want to learn more about the product backlog and the accountability of product owner on a scrum team, a Certified Scrum Product Owner® (CSPO®) course can help. Find one online or in person near you.
Get the latest resources from Scrum Alliance delivered straight to your inbox
Subscribe