Product Backlog
A prioritised list of all work — features, bugs, improvements, and technical debt — that a product team intends to build, ordered by value and urgency.
What is a Product Backlog?
The product backlog is an ordered list of all work the team plans to do, maintained by the Product Owner or PM. Items at the top are well-defined, estimated, and ready for sprint. Items at the bottom are vague — they exist to capture future direction.
Backlog item types
| Type | Description |
|---|---|
| Feature | New functionality for users |
| Bug | Defect in existing behaviour |
| Technical debt | Engineering improvement with no visible user change |
| Spike | Research or investigation task |
| Chore | Infrastructure, ops, or maintenance work |
Healthy vs. unhealthy backlog
| Healthy | Unhealthy |
|---|---|
| Top 2 sprints fully groomed with AC | 500+ items, 3 years old |
| Items deleted when no longer relevant | Nothing ever removed |
| Ordered by value | Ordered by who asked loudest |
| Known to the team | Only the PM knows it exists |
Backlog grooming (refinement)
A regular session (30–60 min/week) where PM and engineering review upcoming items, add acceptance criteria, break down large items, and estimate effort. Output: a sprint-ready top of backlog.
Free templates for Product
Frequently asked questions
How big should a backlog be?
Large enough to always have 2–3 sprints of prioritised work ready. Backlogs with hundreds of stale items are a liability — prune anything not actioned in 6 months. If it matters, it'll come back.
Who should have access to the backlog?
Everyone on the team, read-only. Engineering needs visibility to plan ahead. Design needs it to work on upcoming features. Only the PM should re-order it — 'backlog by committee' is a fast path to incoherent priorities.
Apply Product Backlog to your real product data
PMRead ingests customer feedback, interviews, and Slack threads — and generates PRDs grounded in real evidence.
Related terms
Agile
An iterative approach to software development that delivers working software in short cycles, embraces changing requirements, and prioritises collaboration over documentation.
Scrum
An Agile framework that organises work into fixed-length sprints (1–4 weeks) with defined roles, ceremonies, and artifacts to deliver working software iteratively.
Sprint
A fixed-length iteration (usually 1–2 weeks) in Scrum during which a team completes a set amount of work from the backlog and delivers a potentially shippable increment.