A Product Backlog can be a team's most useful tool or its biggest source of confusion. Well managed, it shows everyone what matters most and why. Badly managed, it becomes a long, unordered wish list that nobody trusts. This guide explains what the Scrum Guide says about the Product Backlog, then gives a practical, step-by-step approach to managing one, including ordering techniques, refinement, sizing and splitting large items.
Key takeaways
- The Product Backlog is an emergent, ordered list of what is needed to improve the product, and the single source of work for the Scrum Team.
- The Product Owner is accountable for managing it, but the Developers size the items and anyone can suggest changes.
- Order the backlog by value, risk, learning and dependencies, always in light of the Product Goal.
- Refinement is an ongoing activity, not a Scrum event; items that can be Done within one Sprint are ready for selection.
- A smaller, well-ordered backlog is far more useful than a long list of every idea anyone ever had.
What is a Product Backlog?
The Scrum Guide describes the Product Backlog as an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. "Emergent" means it keeps changing: items are added, removed, split and reordered as the team and stakeholders learn.
The Product Backlog has a commitment: the Product Goal. The Product Goal describes a future state of the product that the team can plan against, and the rest of the backlog emerges to define what will fulfil it. Our article on Scrum artifacts explains how the Product Backlog relates to the Sprint Backlog and the Increment.
Who is responsible for what?
| Who | Responsibility |
|---|---|
| Product Owner | Accountable for effective Product Backlog management: the Product Goal, clear items, the order and transparency. May delegate the work, but remains accountable. |
| Developers | Responsible for sizing the items they will work on, and involved in refinement. |
| Scrum Master | Helps the Product Owner find effective techniques for managing the backlog, and helps the team understand why clear items matter. |
| Stakeholders | Can suggest changes; anyone who wants to change the backlog does so by convincing the Product Owner. |
For more on the Product Owner's accountability, see our complete Product Owner guide.
What a good Product Backlog looks like
A widely used way to describe a healthy backlog is the acronym DEEP, popularised by Roman Pichler and Mike Cohn. It is not part of the Scrum Guide, but it is a useful check:
- Detailed appropriately: items near the top are clear and small; items further down can be rough.
- Estimated: items near the top have been sized by the Developers.
- Emergent: the backlog changes as the team learns.
- Prioritised: in Scrum terms, ordered, so everyone knows what comes next.
Other signs of health: the backlog connects clearly to the Product Goal, it can be understood by someone outside the team, and it is short enough to review regularly.
How to manage a Product Backlog: step by step
Step 1: Start from the Product Goal
Before adding or ordering anything, make sure the Product Goal is clear and shared. Every item near the top of the backlog should help move the product toward it. If an item does not, question whether it belongs there right now.
Step 2: Capture ideas from the right sources
Backlog items come from many places: customer feedback, support tickets, stakeholder requests, usage data, the Developers' technical insights and the Sprint Review. Capture them, but do not treat every idea as a commitment. Some teams keep new ideas in a separate area until the Product Owner has had a chance to consider them.
Step 3: Write items clearly
The Scrum Guide does not prescribe a format. What matters is that each item is clear enough to discuss. Good items usually explain who benefits, what they need and why it matters. Many teams use user stories for this, but a plain, clear sentence works too.
Our guide on how to write user stories explains the format, acceptance criteria and examples.
Step 4: Order the backlog
Decide what comes first. The next section covers techniques in detail. The key point is that the backlog is ordered, not just labelled "high" or "medium": there should never be ten items all ranked number one.
Step 5: Refine regularly
Break down, clarify and size the items near the top with the Developers. Regular, short refinement sessions work better than rare, long ones.
Step 6: Keep enough ready work
Many teams aim to have roughly one or two Sprints' worth of clear, sized items at the top of the backlog. That gives Sprint Planning a solid starting point without spending effort detailing work that may change.
Step 7: Remove what no longer matters
Delete or archive items that are outdated, duplicated or no longer connected to the Product Goal. A backlog only stays useful if it is pruned.
Step 8: Keep it visible
Share the backlog with stakeholders, and explain the order when asked. Transparency reduces private lobbying and builds trust in the Product Owner's decisions.
Step 9: Adapt after every Sprint Review
The Sprint Review is where the team and stakeholders inspect results and decide what to do next. Update the backlog straight afterwards, while the feedback is fresh. See the five Scrum events explained for how the Review works.
Techniques for ordering the backlog
No single technique is right for every product. Most Product Owners combine judgement with one or more of these common approaches.
Value versus effort
Plot items by how much value they are expected to deliver and how much work they need. Items with high value and low effort go first; low value and high effort go last or are removed. Simple and quick, it works well for everyday decisions.
WSJF (Weighted Shortest Job First)
WSJF divides the cost of delaying an item by its size, so small items with a high cost of delay rise to the top. It is based on Don Reinertsen's work on product development flow and is used in some scaled Agile frameworks. It is useful when timing matters, such as regulatory deadlines or market windows.
MoSCoW
Sort items into must have, should have, could have and won't have for now. It is easy for stakeholders to understand and helpful when agreeing the scope of a release, but on its own it does not produce a single order, so the Product Owner still needs to order items within each group.
The Kano model
Developed by Professor Noriaki Kano, this model groups features by how customers react to them: basic expectations that cause dissatisfaction if missing, performance features where more is better, and delighters that customers do not expect. It helps balance fixing basics with creating features that stand out.
Risk and learning first
Some items are valuable because they reduce uncertainty: testing whether customers want something, or proving that a difficult technical approach works. Doing these early can prevent large investments in the wrong direction.
Dependencies
Sometimes an item must come earlier because other work depends on it, or because another team needs it by a certain date.
Whatever technique you use, the result should be explainable in plain language: "This is first because it helps most customers reach the Product Goal soonest."
Product Backlog refinement
The Scrum Guide describes refinement as the act of breaking down and further defining Product Backlog items into smaller, more precise items. It is an ongoing activity that adds details such as a description, order and size. It is not one of the five Scrum events. Earlier editions of the Scrum Guide suggested refinement usually took no more than about 10% of the Developers' capacity; the 2020 edition no longer gives a figure, leaving it to the team.
Running a refinement session
- Prepare: the Product Owner picks the items likely to be needed in the next one or two Sprints.
- Explain the why: for each item, describe the need and who benefits.
- Discuss: the Developers ask questions, raise risks and suggest simpler approaches.
- Split: break down items that are too large to be Done within a Sprint.
- Size: the Developers size the items.
- Update: record what was agreed and adjust the order if needed.
When is an item ready?
According to the Scrum Guide, Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. Some teams use a checklist called a "Definition of Ready". It is not part of Scrum, and if it becomes too strict it can turn into a gate that slows the team down. Used lightly, it can be a helpful reminder.
Sizing Product Backlog items
The Scrum Guide states that the Developers who will be doing the work are responsible for sizing it. The Product Owner may influence them by helping them understand and select trade-offs. Common sizing approaches include:
- Story points: a relative measure of effort, complexity and uncertainty.
- T-shirt sizes: small, medium, large, useful for rough sizing further down the backlog.
- Planning Poker: each Developer chooses a size privately and the team discusses differences, which often surfaces hidden assumptions.
Remember that sizes are forecasts, not promises. Their main value is the conversation they create.
How to split large items
Items that are too big to be Done within a Sprint need to be broken down. Common ways to split them:
- By workflow step: deliver one step of a process first, such as "search" before "book".
- By type of user: deliver for one group of users first.
- By business rule: handle the simple case first and add special rules later.
- By data: support one type of data or one channel first.
- Simple path first: deliver the main path, then add error handling and edge cases.
- Research first: if too much is unknown, do a short piece of investigation work to answer the key question.
A good split still delivers something usable. Splitting by technical layer, such as "database" then "interface", usually does not.
Bugs and technical work
The Product Backlog is the single source of work, so bugs and technical improvements belong in it too. Hiding them elsewhere makes the backlog less transparent and the team's capacity harder to understand. The Product Owner orders them alongside everything else, listening to the Developers about the risk of leaving technical problems unresolved.
An example of an ordered backlog
As an illustration only, here is the top of a Product Backlog for a hotel booking app with the Product Goal "Guests can manage their whole stay without calling the hotel":
| Order | Item | Why it is here |
|---|---|---|
| 1 | Guests can see and change their check-in time | Most common reason guests call the hotel |
| 2 | Fix: booking confirmation email sometimes not sent | Causes calls and lost trust |
| 3 | Guests receive a reminder the day before arrival | Small effort, reduces missed check-ins |
| 4 | Test whether guests want to order room service in the app | Learning before a larger investment |
| 5 | Guests can request late check-out | Valuable, but depends on item 1 |
Managing one backlog across several teams
When several Scrum Teams work on the same product, the Scrum Guide says they share one Product Backlog, one Product Goal and one Product Owner. The backlog then needs to show clearly which items depend on each other, and refinement often includes people from more than one team so that work fits together.
Product Backlog vs roadmap vs Sprint Backlog
These three are often confused. They serve different purposes:
| Product Backlog | Product roadmap | Sprint Backlog | |
|---|---|---|---|
| What it is | Ordered list of everything that might improve the product | High-level view of direction and themes over time | The Sprint Goal, selected items and the plan to deliver them |
| Part of Scrum? | Yes, a Scrum artifact | No, an optional practice | Yes, a Scrum artifact |
| Owned by | Product Owner (accountable) | Usually the Product Owner or product leadership | Developers |
| Time horizon | Ongoing | Months or longer | One Sprint |
| Level of detail | Detailed at the top, rough further down | Broad themes and goals | Detailed enough to inspect progress daily |
A roadmap can help stakeholders see direction, but it should not freeze the Product Backlog. When the two disagree, the backlog reflects the latest learning.
Handling stakeholder requests
New requests arrive constantly. A simple, consistent process keeps the backlog under control and treats stakeholders fairly:
- Understand the problem. Ask what the stakeholder is trying to achieve, not just what they want built.
- Check it against the Product Goal. Does it move the product toward the current goal?
- Estimate the value and urgency. Who benefits, how much, and what happens if it waits?
- Place it in the order. Decide where it fits, and be clear about what it sits above and below.
- Explain the decision. Tell the stakeholder where the item is and why. A clear "not now, because" builds more trust than silence.
How to check your backlog is healthy
A few simple measures help a Product Owner see whether the backlog is working:
- Ready work: is there roughly one to two Sprints' worth of clear, sized items at the top?
- Age of items: how many items have sat untouched for months? Old items are candidates for removal.
- Size of the backlog: can the whole backlog still be reviewed in a reasonable time?
- Connection to the Product Goal: can every item near the top be linked to the goal?
- Balance: does the backlog include necessary technical work and bug fixes, not only new features?
- Time from idea to Done: how long do valuable items take to reach customers once they are added?
Tools for backlog management
Scrum does not require any tool. A physical wall with cards can hold a small backlog perfectly well. Most teams, especially remote ones, use a digital backlog tool so the backlog can be shared, searched and ordered easily. When choosing or configuring a tool, favour simplicity: a clear order, short item descriptions and easy access for stakeholders matter more than detailed fields and workflows.
Common problems and how to fix them
- The endless wish list. Hundreds of items nobody reads. Prune aggressively and keep ideas separate until they are genuinely considered.
- Everything is top priority. Force a single order. If two items cannot be separated, ask which one better serves the Product Goal.
- Too much detail too early. Detailed specifications for work months away usually go to waste. Detail items just before they are needed.
- Stakeholders bypass the backlog. Requests sent straight to Developers undermine transparency. Route them through the Product Owner.
- Technical work is never ordered. Include it in the backlog and discuss its value openly.
- Refinement only happens in Sprint Planning. Planning becomes long and uncertain. Refine regularly during the Sprint.
Build your backlog management skills
Backlog management is at the heart of the Product Owner role. Product Owner Plus (Associate) covers product vision, backlog management and stakeholder alignment. The exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. See the certification page for current learning paths and prices. For the day-to-day role, read what does a Product Owner do?, and for a flow-based alternative to Sprints, see Kanban vs Scrum.
Frequently asked questions
Who manages the Product Backlog?
The Product Owner is accountable for managing it. They may delegate some of the work but remain accountable.
Who can add items to the Product Backlog?
Anyone can suggest items, but the Product Owner decides what goes in and in what order. The Scrum Guide says people who want to change the backlog do so by convincing the Product Owner.
Who estimates Product Backlog items?
The Developers who will do the work are responsible for sizing it.
Is backlog refinement a Scrum event?
No. It is an ongoing activity that happens throughout the Sprint.
How much time should refinement take?
The 2020 Scrum Guide does not specify. Earlier editions suggested about 10% of the Developers' capacity; many teams still use that as a rough guide.
What is the difference between prioritising and ordering?
Prioritising often means labelling items high, medium or low. Ordering means putting every item in a single sequence, so there is always a clear "next".
Should bugs go in the Product Backlog?
Yes. The Product Backlog is the single source of work for the Scrum Team, so bugs and technical work belong there too.
How big should a Product Backlog be?
There is no rule. It should be small enough to review regularly and understand. Many teams keep only a few Sprints' worth of detailed items and a short list of broader ideas.