A product backlog that keeps growing without ever being sorted turns into an unmanageable wish list. Here's how to build it, prioritize it, and keep it alive sprint after sprint.
The product backlog, as described in the Scrum Guide, is the ordered list of everything that could be done on a product: new features, bug fixes, technical debt, improvements. Unlike a plain to-do list, it's ordered by priority and lives continuously — never frozen, never "complete".
The backlog is different from breaking work into epics: an epic structures work by major theme, the backlog orders what to do first within (and across) those themes. See also the general definition of the Scrum framework on Wikipedia.
Customer feedback, internal ideas, technical debt: everything goes into the backlog, even fuzzy ideas to be refined later.
A method like MoSCoW or a value/effort score prevents handling requests in the order they came in.
Only the next 1-2 sprints' worth of items need to be precisely detailed — the rest can stay deliberately fuzzy.
An idea never prioritized after several months is probably stale: better to archive it than let the backlog grow indefinitely.
The DEEP rule: a good backlog is appropriately Detailed, Estimated, Emergent (it evolves), and Prioritized. The last point matters most: without clear prioritization, the rest is pointless.
See project manager vs Product Owner to clarify who decides the backlog order.
Developers estimate the effort for each item, often in points or days, to inform priority decisions.
Clients and users suggest ideas, but don't directly prioritize the backlog.
The backlog's major themes roll up into the longer-term product roadmap.
See also the official resource Scrum.org: What is a Product Backlog.
Centralize your ideas, prioritize them, and turn them into sprint tasks in one click. Free.