Scrum guide · Artifacts and practices
Product Backlog in Scrum: What It Is and How to Manage It
The Product Backlog is an emergent, ordered list of what is needed to improve the product. In Scrum it is the single source of work undertaken by the Scrum Team, and its commitment is the Product Goal.
Key takeaways
- The Product Backlog is an emergent, ordered list and the single source of work for the Scrum Team.
- The Product Owner is accountable for it; the Developers size the items.
- Its commitment is the Product Goal, which gives the backlog direction.
- Keep it short, ordered and refined at the top, and remove items that no longer add value.
What the Product Backlog is
The Product Backlog is one of the three Scrum artifacts, alongside the Sprint Backlog and the Increment. It holds everything the Scrum Team currently believes could add value to the product: new features, changes, fixes, technical work, research and experiments.
- Emergent: it is never complete. Items are added, changed and removed as the team and stakeholders learn.
- Ordered: items have a clear order, so everyone can see what will be worked on next. The 2020 Scrum Guide says ordered rather than prioritised, because order can reflect value, risk, dependencies and learning as well as priority.
- Single source of work: if the Scrum Team is going to work on it, it should be visible in the Product Backlog.
- One per product: several Scrum Teams working on the same product share one Product Backlog and one Product Owner.
Who owns the Product Backlog
The Product Owner is accountable for effective Product Backlog management. Under the 2020 Scrum Guide that includes:
- Developing and explicitly 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 do some of this work, but remains accountable. The Developers who will do the work are responsible for sizing items, and the Scrum Master helps the Product Owner find effective techniques for backlog management. Anyone who wants to change the Product Backlog does so by persuading the Product Owner.
The Product Goal
The Product Goal describes a future state of the product that the Scrum Team plans for. It sits in the Product Backlog, and the rest of the Product Backlog emerges to define what will fulfil it. The team should fulfil or abandon one Product Goal before taking on the next.
| Level | Commitment | Example |
|---|---|---|
| Product Backlog | Product Goal | Customers can manage their whole account online without calling support |
| Sprint Backlog | Sprint Goal | Customers can download past invoices as PDFs |
| Increment | Definition of Done | Code reviewed, tested, accessible and deployed to production |
What goes into a Product Backlog item
The Scrum Guide does not prescribe a format. Attributes vary with the domain of work, but most teams record:
| Attribute | Purpose |
|---|---|
| Description | What is needed and why; often written as a user story |
| Order | Its position relative to other items |
| Size | An estimate by the Developers, for example in story points |
| Acceptance criteria | Conditions that confirm the item does what it should |
| Value or rationale | The outcome or benefit expected |
| Notes and links | Designs, research, dependencies or related epics |
Items near the top are small, clear and detailed. Items further down can be larger and vaguer, because detail added too early is often wasted. Items that can be Done within one Sprint are considered ready for selection in Sprint Planning.
How to manage a Product Backlog, step by step
- Write down the Product Goal and share it with the team and stakeholders.
- Capture ideas, requests and known work as items, without worrying about detail for now.
- Order the items, considering value, risk, cost, dependencies and what the team needs to learn.
- Refine the top of the backlog regularly so the next one or two Sprints' worth of items are clear and sized; see backlog refinement.
- Use the Sprint Review to inspect progress with stakeholders and adapt the backlog.
- Remove items that no longer support the Product Goal, so the backlog stays short and useful.
- Track progress towards the Product Goal with a burnup chart or forecast; see Scrum metrics.
Worked example: ordering a small backlog
A Product Owner for an online booking service has the Product Goal "Customers can book and change appointments without phoning us". The Developers have sized the items. The Product Owner orders them by weighing value against size and risk:
| Order | Item | Size (points) | Reason for its position |
|---|---|---|---|
| 1 | Book an appointment online | 8 | Core to the Product Goal; nothing else is useful without it |
| 2 | Email confirmation after booking | 3 | High value, small, reduces no-shows |
| 3 | Change or cancel a booking | 5 | Directly reduces phone calls |
| 4 | Spike: calendar provider integration | 2 | Reduces risk before item 5 |
| 5 | Sync bookings to staff calendars | 8 | Valuable but depends on what the spike learns |
| 6 | Loyalty discount codes | 13 | Not needed for the current Product Goal |
If the team's velocity is around 15 points, items 1 to 3 (16 points) are slightly more than one Sprint, so the team might plan items 1 and 2 plus the spike, then take item 3 next Sprint. Item 6 may be removed or parked until a later Product Goal.
Product Backlog vs Sprint Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Contents | Everything that might improve the product | Sprint Goal, selected items and a plan |
| Accountable | Product Owner | Developers |
| Commitment | Product Goal | Sprint Goal |
| Time horizon | The life of the product | One Sprint |
| Changes | Whenever the Product Owner reorders or adds items | Daily, as the Developers learn |
Common mistakes
- A backlog that only grows. Hundreds of old items hide what matters. Delete or archive items that no longer serve the Product Goal.
- Several backlogs for one product. Separate team backlogs make ordering across the product impossible.
- Everything is "high priority". Order is a strict sequence, not a set of labels.
- Too much detail too early. Detailed specifications for items months away are usually rewritten.
- The Product Owner works alone. Refinement works best as a collaboration with the Developers and stakeholders.
- No Product Goal. Without it, the backlog becomes a list of requests rather than a plan for value.
Free templates for this topic
Frequently asked questions
What is a Product Backlog in Scrum?
It is an emergent, ordered list of what is needed to improve the product, and the single source of work for the Scrum Team. Its commitment is the Product Goal.
Who owns the Product Backlog?
The Product Owner is accountable for it. Others can contribute and may be asked to do some of the work, but the Product Owner decides the order.
Who can add items to the Product Backlog?
Anyone can suggest items, and in many teams Developers add items directly. The Product Owner remains accountable for the contents and order.
What is the difference between a prioritised and an ordered Product Backlog?
Prioritising often means labelling items high, medium or low. Ordering means putting every item in a single sequence, which can reflect value, risk, dependencies and learning.
How does the Product Goal relate to the Product Backlog?
It is the commitment for the Product Backlog: a future state of the product that the Scrum Team plans for. The team works on one Product Goal at a time.
How big should a Product Backlog be?
There is no rule. A backlog that is too long to read and order becomes hard to manage, so many teams keep detailed items to a few Sprints' worth and hold the rest as larger, coarse items.
Do Product Backlog items have to be user stories?
No. The Scrum Guide does not prescribe a format. User stories are popular, but items can also be bugs, technical tasks, experiments or plain descriptions.
Who estimates Product Backlog items?
The Developers who will do the work are responsible for sizing. The Product Owner can help them understand items and trade-offs.
When is a Product Backlog item ready?
The Scrum Guide says items that can be Done within one Sprint are deemed ready for selection in Sprint Planning. Some teams add an optional Definition of Ready.
Can multiple teams share one Product Backlog?
Yes. In Scrum, one product has one Product Backlog and one Product Owner, even when several teams work on it.
Is the Product Backlog the same as a project plan?
No. It is an evolving list for the product rather than a fixed plan, though it can be used with forecasts and a release plan.
What tools can I use for a Product Backlog?
Anything from a spreadsheet or sticky notes to tools such as Jira or Trello. See Scrum software tools.