Product Backlog
A product backlog is the ordered list of everything needed to improve a product and the single source of work for the team that builds it. It holds user stories, bug fixes, technical work and other items. The product owner keeps it ordered by value, so items at the top are clear and small enough to start, while lower items stay rough until they rise.
How a Product Backlog Works
The Scrum Guide describes the product backlog as an emergent, ordered list of what is needed to improve the product. Both words matter. Emergent means the backlog is never finished: items are added, changed and removed as the team learns from customers, data and its own releases. Ordered means every backlog item has a position, so there is no ambiguity about what comes next. Ordering weighs value against cost, risk, dependencies and learning, not just a priority label.
Accountability is clear in Scrum. The product owner is accountable for managing the backlog, including writing and ordering items, even when others help with the work. Developers are responsible for sizing items, because they are the ones who will build them.
Detail is uneven by design. Items near the top are refined until they can be completed within one sprint, at which point the Scrum Guide calls them ready for selection in Sprint Planning. Items further down can be one-line ideas or large epics. This keeps the team from spending effort detailing work that may never be built. The ongoing work of adding detail, splitting and resizing items is backlog refinement.
Since 2020, the Scrum Guide also ties the backlog to a Product Goal: a description of a future state of the product that the team plans against. The goal gives the backlog a direction, so items can be judged by whether they move the product toward it.
Why a Product Backlog Matters
A single ordered list makes trade-offs explicit. When everything competes in one place, stakeholders can see what is being done next and what is being postponed, and the product owner has one tool for saying "not yet" with a reason.
It also protects the team's focus. Developers pull work from the top of one list instead of fielding requests from several channels. And because the backlog is emergent, it lets the plan change cheaply: reordering a list costs far less than rewriting a fixed project plan. For how a backlog can carry strategic context down to individual tickets, see turning product vision into a sprint-ready backlog.
Product Backlog Example
A team building a scheduling app has a Product Goal of making the app usable for small clinics. The top of its backlog holds three refined stories for clinic opening hours, a bug where reminders arrive twice and a spike on calendar sync, each sized and ready for the next sprint. Further down sit a rough epic for multi-location support and a one-line idea about SMS reminders. When interviews show that clinics care most about reducing no-shows, the product owner moves SMS reminders up, and the team refines it in the next session.
Product Backlog vs. Sprint Backlog
The product backlog covers the whole product and changes continuously. The sprint backlog is the team's plan for a single sprint: the Sprint Goal, the product backlog items selected for that sprint and a plan for delivering them. The developers own the sprint backlog and update it daily, while the product owner is accountable for the product backlog.