What Belongs in a Product Backlog

Close

A product backlog contains the possible future work for a product.

That work is often expressed as user stories. But a product backlog is not simply a list of user stories. It can include features, bugs, technical work, learning items, experiments, improvements, and other work that may help the product.

A good product backlog item helps the Product Owner and team make a decision. It may improve the product, reduce uncertainty, satisfy an important constraint, or help the team learn something needed for a better product decision.

Who This Page Is For

This page is for Product Owners, Scrum Masters, agile coaches, Developers, analysts, testers, designers, stakeholders, and leaders who want clearer expectations about what should and should not go into a product backlog.

It is especially useful for teams deciding whether bugs, technical work, spikes, chores, stakeholder requests, or non-user-story items belong in the backlog.

What This Page Covers

You will learn what types of work belong in a product backlog, why not every item needs to be a user story, how product backlog items differ from sprint tasks, who can add items, and how to decide whether an item deserves to stay.

A Product Backlog Is More Than User Stories

User stories are useful for many product backlog items, especially user-facing functionality.

Some backlog items describe bugs. Some describe technical improvements. Some describe learning the team needs before making a larger decision. Some describe product improvements that do not fit naturally into the user story template.

Use a user story when the format helps. Use another format when that creates a better conversation.

Common Types of Product Backlog Items

Features

Features are the most common type of product backlog item.

A feature describes something the product may do for a user, customer, stakeholder, or market. Many features are written as user stories because user stories keep the conversation focused on who wants something, what they want, and why it matters.

For example:

As a shopper, I can review the items in my shopping cart before checking out so that I can see what I’ve already selected.

Bugs and Defects

Bugs often belong in the product backlog.

Fixing a bug can be one of the most valuable things the team can do to improve the product. A bug may affect customer satisfaction, revenue, support cost, reliability, security, or trust.

The Product Owner should still make tradeoffs. Some bugs should move near the top. Some can wait. Some may never be worth fixing.

Technical Work

Technical work can belong in the product backlog when it affects the product or the team’s ability to improve the product.

Examples might include upgrading a framework, improving performance, automating part of a deployment pipeline, reducing technical debt, improving observability, or replacing an unsupported library.

Technical work should not be hidden. If it matters enough to compete with feature work, it should be visible enough for the Product Owner and team to discuss.

The key is to connect the technical work to a product or delivery outcome. “Upgrade the database” is easier to discuss when the team understands whether the goal is better performance, lower support risk, improved security, or enabling upcoming functionality.

Learning Items

Sometimes the team needs to learn something before it can make a responsible product decision.

A learning item may involve researching an API, testing whether a technology works as expected, building a small prototype, running an experiment, or exploring user behavior before committing to a larger feature.

These items are sometimes called spikes, research items, discovery items, or experiments.

They belong in the product backlog when the learning will help the Product Owner or team decide what to do next.

Product Improvements

Some product backlog items improve something that already exists.

Examples include simplifying a workflow, improving an error message, reducing the number of clicks in a common task, making a page more accessible, or clarifying confusing language.

These are valid product backlog items because they improve the product.

Product Backlog Items Can Be Written in Different Ways

A backlog can contain different types of work, and those items can be written in different ways.

A feature might be written as a user story. A bug might be written as a bug report. A learning item might be written as a question to answer or a timeboxed spike. Technical work might be written as a short descriptive item.

The wording matters only when it helps the conversation.

When User Stories Help

User stories work especially well when the user matters.

They are useful when different users have different needs, goals, permissions, or behaviors. The “As a...” part of the template helps the team think about who wants the capability and why.

When Job Stories Help

Job stories can help when the situation matters more than the user role.

If many stories start with “As a user,” the user may not be providing much useful information. A job story can put more attention on the context or trigger:

When an order is submitted, I want to see a warning message so I can avoid submitting the order twice.

Job stories and user stories can live in the same backlog. The goal is clarity.

When FDD-Style Feature Descriptions Help

Some product backlog items describe back-end, API, integration, or system behavior where forcing a user story would feel artificial.

Feature-Driven Development, or FDD, is an older agile approach that used a simple feature syntax that still works well for items like these.

For example:

  • Generate a unique identifier for a transaction
  • Merge duplicate customer records
  • Estimate the closing price of a stock
  • Change the text displayed on a kiosk

These are still product backlog items if they represent work that may improve the product or support a valuable product outcome.

What Makes Something a Product Backlog Item?

A possible product backlog item should pass a simple test:

Does this represent work we may do to improve the product or reduce uncertainty about the product?

That test helps distinguish real product backlog items from random notes, tasks, promises, and ideas that are not ready for the team’s attention.

A good product backlog item usually has at least some of these qualities:

  • It is connected to a product goal, user need, stakeholder need, technical need, or learning need
  • The Product Owner can decide whether it is worth doing before other work
  • The team can eventually refine it into something small enough to complete in a sprint
  • It leads to a useful conversation about value, risk, cost, learning, or completion
  • It can be changed, split, reordered, or removed as the team learns

A product backlog item does not need to be perfectly written when first added. It should eventually become clear enough to support a real planning decision.

Product Backlog Items Are Not Sprint Tasks

Product backlog items and sprint tasks are different.

A product backlog item describes product work the team may do. A sprint task describes part of how the team plans to do that work during a sprint.

For example, a product backlog item might be:

As a shopper, I can save items for later so that I can return to them before checking out.

During Sprint Planning, the team might identify tasks such as:

  • Update the cart database table
  • Add the save-for-later button
  • Write automated tests
  • Update the empty-state message
  • Review the design with UX

Those tasks help the team organize sprint work. They usually do not belong in the product backlog as separate items because none of them delivers meaningful product value by itself.

Who Can Add Product Backlog Items?

Anyone can suggest a product backlog item.

A Developer may notice technical work that should be considered. A tester may identify a bug or edge case. A designer may suggest a usability improvement. A stakeholder may request a capability. A customer may raise a problem. A support person may spot a recurring issue.

The Product Owner does not need to be the source of every idea.

But the Product Owner is accountable for what happens to those ideas. The Product Owner decides whether an item stays, moves up, moves down, is rewritten, is split, is archived, or is deleted.

What Should Not Go in the Product Backlog?

A product backlog should not contain everything anyone can think of.

Be cautious about adding:

  • Current-sprint tasks that belong in the sprint backlog
  • Vague notes no one can explain
  • Duplicate requests
  • Old ideas that no longer fit the product direction
  • Work that has no product, technical, learning, or risk-reduction value
  • Items added only because someone does not want to say no
  • Far-future ideas that would be better kept in a separate idea list
  • Personal reminders for the Product Owner or team

Some of these can be rewritten into useful product backlog items. Others should be deleted or kept somewhere else.

Keep Product Boundaries Clear

Before deciding what belongs in a product backlog, make sure the team understands what product the backlog is for.

One product should have one product backlog. Organizations still need to decide what counts as a product.

A product might be customer-facing software, an internal system, a shared service, a component used by multiple teams, a digital product, a physical product, or a service. The key is that it provides value to some market, user group, or customer group.

Poor product boundaries create backlog confusion. A clear product boundary helps the Product Owner decide whether an item belongs in this backlog, another backlog, or nowhere at all.

Add Detail Just in Time and Just Enough

Items do not need the same amount of detail when they are first added.

A far-future idea can be brief. A product backlog item being considered for an upcoming sprint needs more detail. As an item moves toward the top of the backlog, the Product Owner and team refine it, split it if needed, add acceptance criteria, identify risks, and decide whether it is ready enough for Sprint Planning.

Too little detail near the top creates confusion. Too much detail too early creates waste.

Common Mistakes About What Belongs in a Product Backlog

Treating Every Product Backlog Item as a User Story

Use user stories when they help the conversation. If the template makes wording awkward, use a better format. For more detail, see Not Everything Needs to Be a User Story.

Turning Product Work Into Technical Tasks

Avoid splitting a backlog item into technical layers. Product backlog items should usually describe value, risk reduction, or learning rather than implementation tasks. For more detail, see The Difference Between a Story and a Task.

Letting Stakeholder Requests Become Commitments

A stakeholder request is input, not a commitment. The Product Owner still decides whether it belongs and how important it is. For more detail, see Who Can Add Items to the Product Backlog?.

Ignoring Learning Work

Research, spikes, and experiments belong when learning helps the team avoid waste, reduce risk, or make a better product decision. For more detail, see Agile Spikes.

Is This a Good Product Backlog Item?

Use these questions when deciding whether an item belongs in the product backlog.

  • Does this item improve the product or reduce uncertainty about the product?
  • Can the Product Owner make a tradeoff decision about it?
  • Is it connected to a user, customer, stakeholder, technical, learning, or risk-reduction need?
  • Is it visible enough that the team can discuss it honestly?
  • Is it a product backlog item rather than a sprint task?
  • Can it eventually be refined into something the team can complete in a sprint?
  • Does it belong in this product backlog, another product backlog, or a separate idea list?
  • Should it be kept, rewritten, split, archived, or deleted?

FAQ

Does every product backlog item need to be a user story?

No. User stories are useful for many product backlog items, especially user-facing functionality. A product backlog can also include bugs, technical work, learning items, experiments, job stories, FDD-style features, and other useful forms.

Do bugs belong in the product backlog?

Often, yes. Fixing a bug may be one of the most valuable ways to improve the product. The Product Owner should still decide how important the bug is compared with other work.

Does technical work belong in the product backlog?

Yes, when it matters enough to compete with other product work. Technical work belongs in the backlog when it improves the product, reduces risk, enables future work, improves delivery capability, or protects the product from avoidable problems.

Do spikes or research items belong in the product backlog?

Yes, when the learning will help the Product Owner or team make a better decision. A spike, research item, experiment, or prototype can reduce uncertainty before the team commits to larger work.

Who can add items to the product backlog?

Anyone can suggest or add an item if the team’s working agreement allows it. The Product Owner decides what happens to it.

Are tasks product backlog items?

Usually not. Tasks are normally part of the sprint backlog. They describe how the team plans to complete selected product backlog items during a sprint.

Can non-functional requirements be product backlog items?

If a non-functional expectation applies broadly, it often belongs in the team’s Definition of Done. If the product does not currently meet that expectation and work is needed to improve it, treat that work like a product improvement or feature and put it in the backlog.

What if an item is just an idea?

Some ideas are worth keeping in the product backlog. Others belong in a separate idea list until the Product Owner decides whether they deserve the team’s attention. Some should be deleted.

How much detail should a new product backlog item have?

Enough detail for the decision being made now. A new or far-future item can be brief. An item near the top of the backlog should be clear enough for refinement, estimation, prioritization, and Sprint Planning.