Product Backlog

A product backlog is the single, ordered list of everything that might be built or fixed for a product — the one authoritative source of work, kept prioritised by value and continuously refined.

A product backlog is an ordered, ever-evolving list of the features, changes, fixes and other work items that could add value to a product. It is owned by the Product Owner, who orders it so the most valuable items are at the top and ready to be worked. Items near the top are small and well-understood; items lower down are larger and vaguer, refined over time as they rise in priority. The backlog is the single source of truth for what the team may work on — there is no separate list.

Why it matters

A single ordered backlog solves two problems at once: it prevents work from living in scattered emails and side-channels, and it forces explicit prioritisation. Because it is ordered by value, the team always knows what matters most next, and stakeholders can see where their request sits. Because it is continuously refined rather than fixed, it lets the product adapt as understanding grows — the Agile answer to a fixed scope baseline.

When to use it

Use a product backlog in any Agile or product-driven effort — Scrum mandates it, and it suits any team delivering incrementally. It is less relevant to fixed-scope predictive projects, which use a WBS and baselined scope instead, though even those benefit from a prioritised change/enhancement list.

How to use it

1. Capture all candidate work as backlog items (often user stories, plus bugs and technical work).
2. Have the Product Owner order the list by value, risk and dependency.
3. Refine continuously: split large items, add detail and estimates to items nearing the top.
4. Attach acceptance criteria and a shared definition of ready before an item enters a sprint.
5. Pull the top, ready items into each sprint or into flow as capacity allows.

Example

A product backlog for a booking app has, at the top, "guest can cancel a booking" (small, detailed, estimated) and lower down "loyalty programme" (a large, vague epic). As the cancellation feature ships, the loyalty epic rises, gets split into stories and refined — so the top of the backlog is always ready to build.

Template

A backlog needs items with a title, value/priority, estimate, acceptance criteria and a definition of ready — start from a user-story and backlog template.

Browse templates →

Tools

Related topics

FAQs

Alternatives

• Work Breakdown Structure — the predictive equivalent (fixed tree vs ordered list)
• Roadmap — higher-level, outcome-oriented view above the backlog
• Kanban backlog — an unordered intake feeding a flow board