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.
In This Page
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
User stories are helpful, but they are not mandatory for every item. If the story format creates awkward wording, use another format.
Hiding Technical Work
Technical work should not be hidden outside the backlog if it competes with product work. Make it visible, explain why it matters, and make an informed tradeoff.
Turning Product Work Into Technical Tasks
Splitting a product backlog item into technical layers can make the backlog look detailed while reducing its usefulness. Product backlog items should usually describe valuable outcomes or useful learning.
Adding Every Idea Forever
A backlog that preserves every idea becomes harder to use. Some ideas should be deleted, archived, moved to a separate idea list, or rewritten before they deserve a place in the backlog.
Letting Stakeholder Requests Become Commitments
A stakeholder request is input. The Product Owner still decides whether the item belongs, how important it is, and when the team should consider it.
Ignoring Learning Work
Some teams resist adding research, spikes, or experiments because they do not look like finished features. Learning can be valuable work when it helps avoid waste, reduce risk, or make better product decisions.
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?
Common Questions About What Belongs in a Product Backlog
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.
Recommended Articles and Pages
Scrum Product Backlog
A foundational explanation of the Scrum product backlog, including features, bugs, technical work, and knowledge acquisition.
Not Everything Needs to Be a User Story: Using FDD Features
Explains why some product backlog items are better expressed as features rather than forced into user story format.
Job Stories Offer a Viable Alternative to User Stories
Shows when job stories may be more useful than user stories and how the two can coexist in the same backlog.
The Difference Between a Story and a Task
Clarifies the difference between product backlog items and sprint tasks.
Who Can Add Items to the Product Backlog?
Explains that anyone can suggest backlog items, while the Product Owner decides what happens to them.
Agile Requirements Gathering: Three Types of Requirements
Explains known, overlooked, and emergent requirements and why a product backlog must evolve as the team learns.
Writing the Product Backlog Just in Time and Just Enough
Guidance on adding the right amount of detail to backlog items at the right time.
Related Pages
- Story Splitting: Useful when product backlog items are too large to fit comfortably in a sprint.
- Scrum Product Backlog: A Scrum-specific explanation of the Product Backlog as an artifact.
All Articles on This Subtopic
Explore all Mountain Goat Software articles related to product backlog items, user stories, job stories, technical work, bugs, requirements, tasks, and backlog refinement.
What Belongs in a Product Backlog
- Scrum Product Backlog
- Not Everything Needs to Be a User Story: Using FDD Features
- Job Stories Offer a Viable Alternative to User Stories
- The Difference Between a Story and a Task
- Who Can Add Items to the Product Backlog?
- Agile Requirements Gathering: Three Types of Requirements
- Writing the Product Backlog Just in Time and Just Enough
What Belongs in a Product Backlog Resources
User stories are great. When you’ve got users, that is. Sometimes, though, the users of a system or product are so far removed that a team struggles to put users into their stories. A sign that this is happening is when teams write stories that begin with “As a developer...” or “as a product owner....”...
As useful as user stories can be, they’ve never been right for every team. An exciting alternative for some teams is the job story.
What’s the difference between a user story and a task? Well that’s an easy question, I thought, the first time it was asked of me in a Certified ScrumMaster class. “The difference is …,” I...
My wife, daughters and I use Wunderlist to manage our shared grocery list. Any time one of us notices something we're out of, that person adds it to the grocery list. Then, whoever is taking their turn at doing the weekly grocery shopping checks items off the list while in the store. It works really well. I’m thinking about...
Paste in a user story, job story, technical story, bug, spike, or chore and get coaching on clarity, readiness, testability, and backlog placement.