Skip to content

Product Backlog

At a glance

  • Purpose: Hold every candidate piece of work in one ordered list, so priority is visible and the team always knows what is next.
  • Use it when: Continuously in an agile project. It is ordered, not sorted — one item at a time is genuinely next, and the rest are increasingly uncertain.
  • Owner: The product owner orders it; everyone may propose items.
  • Related: Module 04 · Lab 14
  • Spreadsheet version: csv/product-backlog.csv

How to use this template

  1. Order by value against effort and risk, not by the size of the item. Getting the top of the list right matters more than the bottom being complete.
  2. Write items now, in detail only at the top. A backlog refined to the same depth throughout is documentation, not a plan.
  3. Split any item you cannot estimate or cannot finish in one sprint. "Big" is a signal to split, not to schedule.
  4. Keep a definition of ready gate on items entering a sprint, and a definition of done for leaving it.
  5. Re-order ruthlessly. A backlog where the order never changes is a to-do list, not a prioritisation.

Field descriptions

Column What goes in it Watch out for
ID Stable reference (e.g. PB-014) Renumbering after reordering
Item A user story or a stated outcome Tasks ("design the schema") rather than outcomes
Rationale Why it is worth doing Items carried over with no surviving rationale
Value For whom, and what improves Copied value for every item
Estimate A relative size, or a range if uncertain False precision on unrefined items
Priority / order The position, or a MoSCoW class Everything marked "High"
Dependencies What must exist first Undiscovered external dependencies
Status New / refined / ready / in progress / done / deferred Items in "in progress" for months
Ref Linked change request, risk, or requirement ID Items with no traceable origin

Blank template

# Product Backlog — [Product name]

| | |
| --- | --- |
| **Version** | [n] |
| **Product owner** | [Who] |
| **Last refined** | [YYYY-MM-DD] |

## Ordered backlog

| Order | ID | Item | Rationale | Value | Estimate | Dependencies | Status | Ref |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | PB-001 | [Story or outcome] | [Why now] | [High / Med / Low] | [n pts] | [—] | Ready | [FR-01] |
| 2 | PB-002 | | | | | | Refined | |

## Not yet refined (parking list)

| ID | Item | Why it is parked | Revisit when |
| --- | --- | --- | --- |
| PB-099 | [Item] | [Not understood yet] | [After the first release] |

## Decisions about the backlog itself

| Date | Decision | Reason |
| --- | --- | --- |
| | [e.g. Deferred loyalty programme to release 2] | [e.g. No payment integration yet] |

Worked example

From Lab 14, an admission portal backlog using MoSCoW and relative sizes for teaching. Note that order disagrees with size deliberately:

Order ID Item Value Estimate MoSCoW Status
1 PB-001 An applicant can submit one application High 5 Must Ready
2 PB-005 An administrator can view all submissions High 3 Must Ready
3 PB-002 An applicant can upload a supporting document High 8 Must Ready
4 PB-009 Eligibility rules are applied automatically Medium 13 Should Refined
5 PB-014 Applicants receive a status notification Low 3 Could New
6 PB-021 Programme comparison tool Low 8 Won't Deferred

PB-009 is the largest item but not the first: it delivers medium value and carries the most uncertainty, so it waits until the submission path is proven. PB-014 is small but low value enough to sit below it — a reminder that small does not mean next; the order should follow value and risk, not size. PB-021 is marked Won't for this release rather than deleted, so the decision is visible when someone asks for it again.

Common mistakes

  • A backlog ordered by size or by date. Neither is a priority.
  • Everything marked High priority. If all items are equal, the order carries no information.
  • Tasks instead of outcomes. "Design the database" cannot be accepted by a user or measured.
  • Over-refined detail throughout. Effort spent refining items 80 and 81 is effort not spent delivering.
  • No item for the work already done. Rejected or deferred decisions belong in the decision log, and useful ideas belong on the parking list, so they are not re-litigated.
  • The backlog as a contract. If the list is fixed and complete, you are running a predictive project and should say so.