Product Backlog

Close

The product backlog is the Scrum Team’s ordered list of possible future work for the product.

It includes the work the Product Owner may ask the Scrum Team to build, fix, research, improve, or learn about next. A good product backlog gives the Product Owner, Developers, stakeholders, and leaders a shared view of what might matter next without pretending every future detail is already known.

In Scrum, the product backlog is one of the three artifacts. It makes future product work visible so the Scrum Team can inspect, adapt, and decide what to do next.

Who This Page Is For

This page is for people who want to understand the product backlog as a Scrum artifact.

It is especially useful for:

  • Product Owners who want a clearer explanation of their backlog accountability
  • Developers who want to understand how product backlog items become sprint work
  • Scrum Masters helping teams improve transparency, refinement, and Sprint Planning
  • Stakeholders who want to understand how requests move into Scrum
  • Leaders trying to tell whether a backlog is helping or slowing a Scrum Team

What This Page Covers

This page explains what the product backlog is in Scrum, what belongs in it, who is accountable for it, how it changes over time, and how it connects to Sprint Planning and the Sprint Backlog.

It does not try to cover every backlog practice in depth. For deeper guidance on backlog health, prioritization, refinement, story splitting, and acceptance criteria, use the broader Product Backlog guide and related pages.

What Is a Product Backlog?

A product backlog is an ordered list of what may be needed to improve a product.

It can include features, bugs, technical work, learning items, experiments, improvements, and other work the Product Owner may want the Scrum Team to consider.

The product backlog is not a complete requirements document. It is not a promise that every item will be built. It is not a permanent storage place for every idea anyone has ever had.

The product backlog is a decision-making tool.

It helps the Product Owner and Scrum Team answer questions such as:

  • What should we consider next?
  • What work best supports the Product Goal?
  • What needs more refinement before Sprint Planning?
  • What is too large, vague, or risky to bring into a sprint?
  • What can move lower, wait, or be removed?

A product backlog should change as the Scrum Team learns more about the product, users, customers, stakeholders, market, technology, and risks.

The Product Backlog Is a Scrum Artifact

Scrum has three artifacts:

  • Product Backlog
  • Sprint Backlog
  • Increment

The product backlog represents possible future work. The Sprint Backlog represents the Developers’ plan for the current sprint. The increment represents the usable product work completed during the sprint.

The product backlog’s commitment is the Product Goal. The Product Goal gives the Scrum Team a longer-term objective to plan against. The rest of the product backlog emerges to define what may help achieve that goal.

That matters because a backlog without direction can easily become a list of disconnected requests. The Product Goal helps the Product Owner and Scrum Team see why the ordering matters.

Who Owns the Product Backlog?

The Product Owner is accountable for the product backlog.

That includes:

  • Developing and communicating the Product Goal
  • Creating and clearly communicating product backlog items
  • Ordering product backlog items
  • Ensuring the product backlog is transparent, visible, and understood

The Product Owner may ask others to help with any of this work. Developers, stakeholders, customers, users, support people, salespeople, analysts, designers, and leaders may all contribute ideas, information, feedback, or details.

But accountability stays with the Product Owner.

That distinction is important. A healthy product backlog is collaborative, but it still needs one clear ordering. If everyone owns priority, no one owns priority. The Scrum Team needs one Product Owner who can listen, decide, explain, and adapt.

What Belongs in a Product Backlog?

A product backlog can contain many types of work.

Common product backlog items include:

  • Features
  • Bugs
  • Technical work
  • Learning items
  • Experiments
  • Product improvements
  • Risk-reduction work
  • Compliance or operational work

Many Scrum Teams write product backlog items as user stories. That often works well because user stories keep attention on the user, the goal, and the conversation.

But not every product backlog item needs to be a user story.

A bug may be written as a bug. A technical improvement may be written as technical work. A learning item may be written as a spike or research item. The format should help the Scrum Team understand and discuss the work.

Use the format that creates the best conversation.

The Product Backlog Is Ordered, Not Just Prioritized

Older Scrum descriptions often say the product backlog is prioritized. Current Scrum language says the product backlog is ordered.

That is a useful distinction.

A backlog full of “high priority” items does not help much. Ordering forces tradeoffs. Something is first, something is second, something is later, and some things may not be worth doing at all.

Ordering can consider more than business value. A Product Owner may also consider:

  • Customer or user value
  • Product Goal alignment
  • Learning value
  • Risk reduction
  • Cost of delay
  • Dependencies
  • Urgency
  • Effort or size
  • Stakeholder commitments
  • Technical sequencing

The Product Owner is accountable for the ordering, but good ordering is informed by conversation. Developers may see technical risks or dependencies. Stakeholders may see market timing or customer pressure. Leaders may know strategic constraints.

The Product Owner should use that input, make the tradeoff, and keep the product backlog ordered.

Product Backlog Items Emerge Over Time

A product backlog should be emergent.

That means it changes as the Scrum Team learns. New items appear. Existing items are split, clarified, reordered, merged, or removed. Some ideas disappear because they are no longer worth doing.

This is one of the big differences between a product backlog and a traditional requirements document.

With a traditional requirements document, teams often try to define everything up front. With a product backlog, the Scrum Team accepts that not everything is known yet. The Product Owner keeps enough future work visible to support planning, but detail is added progressively.

Items near the top should usually be clearer and smaller because the Scrum Team may work on them soon. Items farther down can remain larger, rougher, and easier to change.

That is healthy. It avoids wasting time fully defining work that may never be built.

Product Backlog and Sprint Planning

The product backlog feeds Sprint Planning.

Before Sprint Planning, the Product Owner should be prepared to discuss the most important product backlog items and how they relate to the Product Goal. During Sprint Planning, the Developers select items from the product backlog to include in the sprint.

That selection is collaborative.

The Product Owner explains what matters and why. Developers ask questions, discuss tradeoffs, consider their capacity and past performance, and decide what they believe they can complete. The Scrum Team then creates a Sprint Goal and a Sprint Backlog.

A product backlog item does not need to be perfectly understood before Sprint Planning. But if an item is so vague, large, or risky that the Developers cannot make a responsible forecast, it probably needs more refinement before being selected.

Product Backlog Refinement

Product backlog refinement is the ongoing activity of making upcoming product backlog items clearer, smaller, and better understood.

Refinement may include:

  • Adding detail
  • Splitting large items
  • Clarifying acceptance criteria
  • Estimating or re-estimating
  • Identifying risks or dependencies
  • Removing stale items
  • Reordering items as new information emerges

Refinement is not about eliminating every unknown. It is about creating enough shared understanding for responsible planning.

A useful test is this:

Can the Developers reasonably believe this item can be completed within a sprint?

If not, the item may need to be split, clarified, researched, or moved lower until the Product Owner and Developers understand it better.

For deeper help with refinement, use Product Backlog Refinement.

Product Backlog vs. Sprint Backlog

The product backlog and Sprint Backlog are related, but they are not the same thing.

The product backlog is the Product Owner’s ordered list of possible future work for the product.

The Sprint Backlog is the Developers’ plan for the current sprint. It includes the Sprint Goal, the product backlog items selected for the sprint, and the work Developers believe is needed to create a done increment.

A simple way to think about it:

  • The product backlog answers, “What might we do next for the product?”
  • The Sprint Backlog answers, “What are we doing this sprint, and how do we plan to do it?”

The product backlog belongs to product decision-making. The Sprint Backlog belongs to sprint execution and adaptation.

Product Backlog vs. Requirements Document

A product backlog is not a requirements document with a different name.

A requirements document often tries to describe the whole product in detail before development begins. A product backlog accepts that some details should emerge later.

That does not mean the backlog should be vague or careless. Near-term items need enough clarity for the Scrum Team to discuss, estimate, and plan responsibly.

The difference is timing.

Add detail when it helps the next decision. Avoid adding detail so early that the Product Owner and Developers spend time refining work that may change or never be built.

Common Product Backlog Problems

The Backlog Becomes a Warehouse

A product backlog can become a dumping ground for every idea, request, bug, and maybe-someday item.

That makes the backlog harder to use. The Product Owner and Scrum Team have to sift through too much noise to find the next important decision.

Prune regularly. Removing an item is often a sign of good product ownership.

Everything Is High Priority

If everything is marked high priority, the labels stop helping.

Order the backlog. Make tradeoffs visible. Force the conversation about what matters now and what can wait.

Items Near the Top Are Too Vague

Sprint Planning becomes painful when the most important items are still unclear.

If Developers are seeing an item for the first time in Sprint Planning, or if major questions cannot be answered, refinement is probably happening too late.

Items Near the Top Are Too Large

Large items are difficult to estimate, discuss, and complete within a sprint.

Split large items before they become sprint candidates. A large idea can stay lower in the product backlog, but work near the top should usually be small enough for a sprint conversation.

The Product Owner Works Alone

The Product Owner is accountable for the backlog, but that does not mean the Product Owner should maintain it in isolation.

Developers need to contribute technical insight, risks, size information, and implementation tradeoffs. Stakeholders and users provide input about value and need. A healthy backlog is shaped through collaboration.

The Backlog Is Too Detailed Too Soon

Some teams try to specify everything far in advance.

That creates waste. Lower-priority items may change, split, merge, or disappear before the Scrum Team ever works on them. Add detail progressively as items move closer to the top.

The Backlog Is Not Connected to a Goal

A backlog without a Product Goal can become a list of unrelated requests.

The Product Goal helps the Product Owner and Scrum Team decide what belongs near the top, what can wait, and what should be removed.

Is Your Product Backlog Useful for Scrum?

Use these questions to decide whether the product backlog is helping the Scrum Team:

  • Is the product backlog visible and understood?
  • Does the Product Owner keep the backlog ordered?
  • Can the Product Owner explain why the top items matter now?
  • Do the top items support the Product Goal?
  • Are near-term items clear enough for Sprint Planning?
  • Are large items split before they become sprint candidates?
  • Are stale or low-value items removed regularly?
  • Do Developers help refine, estimate, and identify risks?
  • Does the backlog change as the Scrum Team learns?
  • Does the backlog help the Scrum Team decide what to consider next?

Use the answers to find the next backlog conversation your Scrum Team needs to have.

FAQ

What Is a Product Backlog in Scrum?

A product backlog is an ordered list of possible future work for a product. It includes the work the Product Owner may ask the Scrum Team to build, fix, research, improve, or learn about next.

Who Owns the Product Backlog?

The Product Owner is accountable for the product backlog.

Others may contribute ideas, details, estimates, feedback, or questions, but the Product Owner remains accountable for the backlog’s ordering and usefulness.

What Belongs in a Product Backlog?

A product backlog can include features, bugs, technical work, learning items, experiments, improvements, and other work that may improve the product or reduce uncertainty.

Many product backlog items are written as user stories, but not every item needs to be a user story.

Is the Product Backlog the Same as a Requirements Document?

No. A product backlog is ordered, emergent, and continually updated as the Scrum Team learns.

It should contain enough detail for the decisions being made now, especially near the top, but it should not try to specify the entire product up front.

How Detailed Should Product Backlog Items Be?

Near-term items should be clear enough for the Scrum Team to discuss, estimate, refine, and consider during Sprint Planning.

Items farther down the backlog can be larger and less detailed because they may change or disappear before the Scrum Team works on them.

Who Prioritizes the Product Backlog?

The Product Owner is accountable for ordering the product backlog.

Developers, stakeholders, customers, and leaders may all provide input. But the Product Owner is responsible for making the final tradeoffs and keeping the backlog ordered.

How Is the Product Backlog Used in Sprint Planning?

The Product Owner brings the most important product backlog items and explains why they matter.

The Developers discuss those items with the Product Owner and select the work they believe they can complete during the sprint. The selected items become part of the Sprint Backlog.

What Is Product Backlog Refinement?

Product backlog refinement is the ongoing activity of adding detail, splitting items, estimating, clarifying acceptance criteria, identifying risks, and reordering or removing items.

The goal is enough shared understanding for responsible planning, not perfect certainty.

How Is the Product Backlog Different from the Sprint Backlog?

The product backlog is the ordered list of possible future work for the product.

The Sprint Backlog is the Developers’ plan for the current sprint. It includes the Sprint Goal, selected product backlog items, and the work Developers plan to do to create a done increment.