What is a product backlog? Product vs sprint backlog
The Scrum Guide 2020 definition of a product backlog, how it differs from a sprint backlog, who orders it, and how to clean up one that has become a dumping ground.
Written by Phan Lam Duy Khoi
A 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. A sprint backlog covers one sprint: the Sprint Goal, the product backlog items selected for it, and a plan for delivering them, made by and for the Developers.
What is a product backlog?
A product backlog is an emergent, ordered list of what is needed to improve the product. A sprint backlog is different: it is the plan for one sprint, made of the Sprint Goal, the product backlog items selected for it and a plan for delivering them, created by and for the Developers.
The definition is short. The hard part is elsewhere. Picture this illustrative situation: you have just become the Product Owner for an office lunch ordering app. Your predecessor hands over a board with about 240 items (an illustrative number). Almost every item is tagged “High”. Some were created more than a year ago, one just says “Improve UX”, and three separate items all ask for reordering yesterday's meal. Sprint planning is in two days, and the team asks you: “What do we do first this sprint?”
This guide explains the product backlog as the Scrum Guide 2020 describes it, separates it from a sprint backlog and a to-do list, and walks through cleaning up a messy backlog into a list the team can actually use. At the end there is a backlog health checklist you can use straight away.
Why does a backlog turn into a dumping ground?
A backlog does not bloat because someone made one big mistake. It is the result of many small decisions, each of which seemed reasonable at the time.
- Adding is easy, removing feels awkward. Logging a request in the backlog ends the conversation politely. Removing it feels like turning the person down.
- Priority labels lose meaning. When everyone wants their work first, every item becomes “High”, and the label no longer helps anyone choose.
- There is no target to compare against. Without a written Product Goal, there is no way to say an item is off course.
- The backlog gets confused with a technical task list. Lines like “add a column to the orders table” describe how, not who it is for or what should change.
A new PO faces one more difficulty: you do not know the history of each item. Something that looks pointless may be a promise made to a large client. So cleaning a backlog is not about deleting fast. It is about reviewing with reasons and leaving a trail.
How is a product backlog different from a sprint backlog and a to-do list?
The Scrum Guide 2020 describes both artifacts clearly. Each comes with a commitment: the product backlog with the Product Goal, the sprint backlog with the Sprint Goal. A to-do list is not a Scrum concept, but it is often confused with a backlog, so it is included for comparison.
| Aspect | Product backlog | Sprint backlog | To-do list |
|---|---|---|---|
| What it is | An emergent, ordered list of what is needed to improve the product | The Sprint Goal, the items selected for the sprint and a delivery plan | A list of tasks for a person or group, with no set framework |
| Commitment | Product Goal, the Scrum Team's long-term objective | Sprint Goal, the single objective of the sprint | None |
| Who is accountable | The Product Owner, even when the work is delegated | Made by and for the Developers | Whoever wrote it |
| Time span | The whole life of the product | One sprint | Up to the owner |
| Level of detail | Top items clear and small, lower items rough | Detailed enough for the Developers to track progress daily | Up to the writer |
| How it changes | People who want changes convince the PO | Developers update it during the sprint as they learn; scope can be clarified with the PO | The writer edits it |
The easiest point to get wrong is who owns the sprint backlog. It is the Developers' plan, not a list the PO hands down. The PO brings ordered items and a proposal for how the sprint could add value. Breaking work down and planning how to do it belongs to the Developers.
In Scrum, “Developers” means the people in the Scrum Team who create the Increment, not only programmers. Testers, designers or content writers in the team are Developers too when they help build that work.
Who owns and orders the product backlog?
According to the Scrum Guide 2020, the Product Owner is accountable for effective product backlog management. That includes developing and communicating the Product Goal, creating and clearly communicating backlog items, ordering them, and keeping the backlog transparent, visible and understood. The PO may do this work or delegate it, but remains accountable.
This does not mean the PO writes everything alone. Developers, stakeholders or the support team can all propose items. The Scrum Guide says that people who want to change the product backlog do so by trying to convince the PO. The PO's decisions are visible in the content and ordering of the backlog.
Two details are worth remembering. First, the Scrum Guide calls the backlog ordered, not just prioritised. An order forces a choice: only one item can be number one. Second, the Developers who will do the work are responsible for sizing it. The PO explains and answers questions, but does not fill in the estimates.
When many requests are all “urgent”, you need a way of ordering that you can explain to stakeholders. That has its own guide, covering frameworks such as value vs effort, MoSCoW and RICE.
What does a healthy product backlog look like?
Mountain Goat Software notes that items near the top of the backlog should be clearer and smaller than those lower down. The Scrum Guide also says items the Scrum Team can get Done within one sprint are deemed ready for selection at sprint planning. From that, a useful picture is a backlog in three layers:
- The top: enough work for roughly the next one or two sprints (this guide's suggestion; adjust it to your team). Each item is small enough to finish in a sprint, has acceptance criteria, and has been understood and sized by the team.
- The middle: the problem and user are clear, but no detail is needed yet. One sentence describing the outcome and a few open questions are enough.
- The bottom: rough ideas. Nobody needs to write them up until they move near the top.
A healthy backlog is not necessarily short. It means each item has a reason to be there, the order reflects the Product Goal, and the top is always ready. Gradually clarifying items as they move up is product backlog refinement, which the Scrum Guide calls an ongoing activity to add details such as description, order and size.
By contrast, these are signs a backlog is unhealthy:
- Hundreds of items nobody has touched for months, and nobody dares delete.
- Everything is “High priority”, so the label helps no one choose.
- Items are technical tasks (“add an API”, “change the table”) rather than outcomes for users.
- The same request appears several times under different names.
- At sprint planning, nobody understands the top items well enough to size them.
- Nobody in the team can say what the current Product Goal is.
How to clean up a messy product backlog
The process below is this guide's suggestion. The Scrum Guide does not prescribe how to clean a backlog, so adapt it to your team. The first cleanup may take a few sessions. After that, keep a light rhythm through refinement so the backlog does not bloat again.
- Write the Product Goal: One sentence, at the top of the backlog
- Filter each item: Archive, merge, rewrite or leave rough
- Set one order: One item per position
- Refine the top: Clarify and size with the Developers
After each sprint, review the top and filter new items. There is no need to redo the whole backlog.
Step 1 is the foundation. The Product Goal describes a future state of the product the team is aiming for. If there is none, draft one with stakeholders and the team. It does not have to be perfect, but it must be clear enough to ask “does this item help us get there?”.
Step 2 takes the most effort. For each item, go through four questions in order:
One backlog item
- Does this item still serve the Product Goal or a problem users face today? Archive it with a reason and tell the person who asked
- Is this the only copy of this item in the backlog? Merge the duplicates into one item and keep every requester's name
- Does the item say what will change, and for whom? Rewrite it as an outcome; leave the how to the Developers' plan
- Does the team plan to work on it in the next one or two sprints? Leave it rough in the middle or bottom, with only open questions
Place it at the top and take it into refinement so it is ready for sprint planning
Archiving is not deleting. An archived item can still be found, with its reason. If the problem comes back, you have the history. When you tell the requester, explain why and what would make you look at it again.
When rewriting an item as an outcome, you can use the user story format or a plain sentence. Mountain Goat Software points out that not every backlog item needs to be a user story. Genuinely needed technical work, such as upgrading a library that is no longer supported, can still be its own item, as long as it says why it matters.
Step 3, ordering, is the PO's decision. Compare each item against the Product Goal, the impact on users and the risk of waiting. Step 4 happens with the Developers: top items are split, given acceptance criteria and sized.
Example: cleaning up a lunch ordering app's backlog
Back to the office lunch ordering app from the illustrative situation at the start. After talking with the team and stakeholders, the PO writes an assumed Product Goal: “Office staff finish ordering lunch before 10:30 without messaging the restaurant separately.” The table below shows five typical items going through the filter above.
| Original item | Before cleanup | After cleanup | Deciding question |
|---|---|---|---|
| “Redesign the home page” | High, created over a year ago, nobody has mentioned it since | Archived with a reason; the person who suggested it is told | Does not serve the current Product Goal or any problem users are reporting |
| Three “Reorder yesterday's meal” items from sales, support and the CEO | Three separate items, each with its own priority | Merged into one item listing all three requesters; placed at position 2 | Not the only copy |
| “Add a notes column to the orders table” | High, technical description only | Rewritten: “The person ordering can send the restaurant a note, such as less spicy or no onions.” Adding the column is left to the Developers' plan; placed at position 3 | Did not say what changes, or for whom |
| “E-wallet payment” | High, just a title | Rewritten in one sentence: “The person ordering pays in the app instead of transferring money and sending a screenshot to the restaurant.” Left in the middle, with open questions about fees and reconciliation | Now written as an outcome, but not planned for the next two sprints |
| “Bug: the Order button cannot be tapped on small screens” | Medium, buried on page 9 | Moved to position 1 and taken into refinement straight away | Passes all four questions: it blocks users from ordering, so fixing it serves the Product Goal directly |
Two things stand out. The most important item was tagged “Medium” and buried far down the list, because the priority labels had lost their meaning. And the e-wallet item was not dropped, just put in the right place: clear enough not to be forgotten, without spending effort on detail yet.
After this cleanup, the illustrative backlog has far fewer active items, with the rest in the archive. The top three items go into refinement to be split, given acceptance criteria and sized before sprint planning. The question “What do we do first this sprint?” now has an answer based on the Product Goal rather than on labels.
Template: product backlog health checklist
Use this checklist when you first take over a backlog, then on a rhythm your team chooses, for example the top section every sprint and the whole backlog every quarter. Copy it and fill in the thresholds your team agrees on.
PRODUCT GOAL [ ] The Product Goal is written down at the top of the backlog [ ] The Developers and key stakeholders can restate the Product Goal TOP OF THE BACKLOG [ ] Enough items for about [number] upcoming sprints [ ] Each item is small enough to finish within one sprint [ ] Each item has acceptance criteria [ ] The Developers have clarified and sized each item [ ] Each item says what will change, and for whom ORDER [ ] The backlog has a single order, with no two items sharing a position [ ] The order can be explained by the Product Goal [ ] Stakeholders know who to talk to about changing the order HYGIENE [ ] No duplicate items [ ] Items untouched for [number] months have been reviewed [ ] Removed items are archived with a reason, not deleted without a trace [ ] Requesters are told when their item is archived NEXT REVIEW: [date]
If a line fails, do not fix everything at once. Start with the line that affects the next sprint planning, which tends to be the top of the backlog, then work through the rest.
Common product backlog mistakes
- Mass-deleting without telling anyone. The backlog looks tidier, but stakeholders lose trust when their requests vanish. Archive with a reason and tell the requester.
- Writing every item in full detail. Effort spent on an item at the bottom is easily wasted, because the context will have changed by the time it is built.
- Treating the sprint backlog as the PO's assignment list. It is the Developers' plan. The PO proposes value and answers questions, but does not hand out tasks to individuals.
- Filling in estimates yourself. The Developers who will do the work are responsible for sizing. A number the PO enters easily becomes pressure rather than a real estimate.
- Cleaning once and walking away. Without a review rhythm through refinement, the backlog will bloat again within a few months.
- Keeping several backlogs in parallel. A file for the manager, a board for the developers and a private PO list undermine the “single source of work” the Scrum Guide describes.
When a new request arrives, do not rush to add it to the backlog. Find the problem behind it first, then decide where it belongs.
Summary
- A product backlog is an emergent, ordered list of what is needed to improve the product, and the Scrum Team's single source of work. Its commitment is the Product Goal.
- A sprint backlog holds the Sprint Goal, the items selected for the sprint and a delivery plan, made by and for the Developers.
- The Product Owner is accountable for ordering the backlog and may delegate the work while staying accountable. The Developers are responsible for sizing.
- A healthy backlog has a clear, small top, a rougher bottom, and a reason for every item.
- Clean a backlog in four steps: write the Product Goal, filter each item, set one order, refine the top. Archive instead of deleting, and tell the requester.
I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.
Frequently asked questions
What is a product backlog?
A product backlog is an emergent, ordered list of what is needed to improve the product. According to the Scrum Guide 2020, it is the single source of work for the Scrum Team, and the Product Goal lives in it.
What is the difference between a product backlog and a sprint backlog?
The product backlog covers the whole product and the Product Owner is accountable for it. The sprint backlog covers one sprint and holds the Sprint Goal, the selected items and a delivery plan, made by and for the Developers.
Who orders the product backlog?
The Product Owner is accountable for ordering the product backlog. The PO may delegate the work but stays accountable, and anyone who wants to change the backlog does so by convincing the PO.
Sources to check
Related articles
- What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
- What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
- Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
- How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.