Skip to content
Product Lifecycle Templates

Product Backlog

beta  ·  Family delivery-docs  ·  Phase deliver  ·  Sizes lean, full  ·  ~1,850 tokens

The single, ordered, emergent list of work for a product, in service of a Product Goal: what the team might do next, sequenced so the most valuable and most informative work sits at the top. The tactical, output-focused counterpart to the roadmap, and the source the sprint backlog is drawn from.

Fast reference for using the product-backlog bundle. For the full reasoning, history, and sources, read product-backlog_companion.md.

When to use

Section titled “When to use”
  • You have a team delivering against a product and need one ordered, shared list of what to do next.
  • The work comes from more than one source (discovery, stakeholder requests, bugs, tech debt) and needs to be sequenced against each other in one place.
  • You have a Product Goal (or can write one) that the work should serve.
  • You want the top of the list continuously sprint-ready so planning is a selection, not a scramble.

When NOT to use

Section titled “When NOT to use”
  • You have no goal and no owner. A backlog with no Product Goal above it and no single owner of the order is a feature factory with a sort order. Write the goal first, or you are just collecting requests.
  • You are describing strategy, not sequencing work. That is a roadmap (strategic, outcome-focused), not a backlog (tactical, output-focused). Keep them separate; derive the backlog from the roadmap’s next goal, not the reverse.
  • You are a pure Kanban team. The Kanban Method manages uncommitted work as “options” upstream of a commitment point, not as a standing ordered backlog. If you limit WIP and pull, you may not want a backlog at all.
  • You are capturing a decision or a design. Those are an ADR, an RFC, or a design doc, not backlog items.

Backlog or roadmap? (the question people actually have)

Section titled “Backlog or roadmap? (the question people actually have)”
Product Backlog Product Roadmap
Answers “What work, in what order, next?” “Where is the product going, and why?”
Focus Tactical, output (items to build) Strategic, outcome (goals to achieve)
Horizon Now to a few sprints (top); coarse below Quarters to a year
Owner’s act Ordering the list Setting the goals
Feeds The sprint backlog The product backlog

They are a sequence, not a choice: the roadmap’s next goal scopes the backlog. The failure is a roadmap that is secretly a feature list, which makes the backlog a feature factory.

Pick a variant

Section titled “Pick a variant”
  • Lean (default): Product Goal, Backlog Items, Ordering Rationale, Refinement and Readiness. A complete working backlog for a single team with one clear goal.
  • Full: adds a Prioritization Framework, Dependencies and Risks, and Backlog Health and Metrics. Use it when multiple teams or stakeholders dispute the order, there are real cross-team dependencies, or the list is large enough that its health must be measured.

Grow lean into full by adding sections; never reorder the shared ones. The scaling signal is scale and contention, not the age of the product.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”
  • There is one measurable Product Goal at the top, and the backlog serves it.
  • The list is genuinely ordered (a true sequence, 1 = next), not just bucketed by priority label.
  • The top items are sprint-ready (small, clear, testable) and the bottom items are coarse (the iceberg), not everything detailed to the same depth.
  • Each item states the value or problem it serves, not just a feature name.
  • The ordering rationale is stated and accounts for risk and dependencies, not only raw value.
  • Refinement is continuous and shared, and readiness is a lightweight heuristic, not a rigid stage-gate.
  • (Full) The prioritization framework, if any, informs the order without overriding judgment.
  • (Full) Dependencies are explicit, and risky assumptions are ordered to be retired early.
  • (Full) The backlog’s health is measured (size, age, pull-depth) and there is an archive rule.
  • The backlog is not just growing: stale items are archived, not hoarded.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. The feature factory. A backlog of pre-decided features with no Product Goal, so the team ships output that moves no outcome. Write a measurable goal and filter items against it.
  2. Backlog bankruptcy. A backlog that only grows, spanning years, most of it never pulled. Delete aggressively; archive is recoverable, lost focus is not.
  3. Must-have inflation. Under MoSCoW, everything becomes a “Must,” which defeats the framework. Force a true order even within a priority band.
  4. The rigid Definition of Ready. A readiness checklist enforced as a stage-gate, reintroducing the phase-gate bureaucracy agile removed. Keep readiness a heuristic.
  5. Velocity as a target. Using story points to compare teams or push speed, which drives teams to skimp on quality. Estimate to plan, not to pressure.
  6. Ordering by loudest stakeholder. Letting whoever pushes hardest set the order, instead of a stated principle. That is the “backlog administrator” failure in miniature.

No paired skill (yet)

Section titled “No paired skill (yet)”

There is no deliver-product-backlog skill in the product-on-purpose org today, so this bundle’s pairs_with is empty. Until one exists, this template is filled by hand.

The artifacts

Section titled “The artifacts”

product-backlog_template-lean.md · ~1,850 tokens

---
title: "{{product_name}} Product Backlog"
product: "{{product_name}}"
product_owner: "{{product_owner}}"
last_refined: "{{date}}"
status: "{{status}}"
doc_type: product-backlog
size: lean
source_template: product-backlog
source_template_version: 0.1.0
---


<!--
LEAN PRODUCT BACKLOG. The smallest backlog that is still a real backlog: a goal, an ordered list of work,
the reason it is in that order, and a way to keep the top of the list sprint-ready. Use it for a single
team with one clear goal. To grow it into a full backlog (see product-backlog_template-full.md), ADD
sections; never rename or reorder the ones below, because the full variant is a strict superset of this one.


A PRODUCT BACKLOG IS A LIVING DOCUMENT, NOT A ONE-TIME DELIVERABLE. Unlike a PRD or a design doc, this is
never "done." Re-order it as you learn, refine the top continuously, and DELETE aggressively: a backlog
that only grows becomes a graveyard nobody trusts. Keep the last-refined date current.


WHAT A PRODUCT BACKLOG IS, AND IS NOT
It is the single ordered list the team draws its work from, in service of a Product Goal. It is NOT a
roadmap (that is strategic and outcome-focused; this is tactical and output-focused), NOT a requirements
document to complete, and NOT a wish list. If it has no goal above it, it is a feature factory with a sort
order. See product-backlog_companion.md sections 1 and 8.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   product-backlog_companion.md for the deep reasoning), guiding questions to ASK, a GOOD and a WEAK
   example, and the TRAP to avoid. For the table, PRIORITY explains the column legend and ROW HINT says
   what a good row contains.
2. Replace each {{placeholder}} with your content. The Backlog Items table is the heart; fill it top-down.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. This document is never finished, but before you share it: self-grade against product-backlog_guide.md,
   then DELETE every HTML comment. They are guidance, not content.
-->


# {{product_name}} Product Backlog


## Product Goal


<!-- WHAT  The one measurable objective this backlog currently serves: a future state of the product the
           team is working toward. One goal at a time.
     WHY   Without a goal above it, an ordered list of features is just a feature factory with a sort
           order. The goal is the backlog's filter: an item that does not help meet it does not belong.
           Deep dive: product-backlog_companion.md section 3 (Anatomy > Product Goal).
     ASK   What future state of the product are we working toward? How will we measure it? Over what
           horizon (weeks to a few months)? What would let us declare it met or abandon it?
     GOOD  "Cut the median time from opening a report to acting on it by 30% for recurring analysts, by
           the end of Q3, measured on the Time to Insight panel."
     WEAK  "Ship more features and improve the dashboard." (not a measurable future state; nothing to
           order the backlog against)
     TRAP  Listing several goals at once. Scrum keeps one Product Goal in play; the team fulfills or
           abandons it before taking on the next. Many goals means no goal. -->


{{product_goal}}


## Backlog Items


<!-- WHAT  The ordered list of work, top to bottom, most valuable and most refined at the top. Items are
           typed (story, bug, tech, spike). Top items are small and sprint-ready; lower items are coarse.
     WHY   This is the backlog. Its order is the Product Owner's core decision, and its shape should follow
           the iceberg: a small, detailed, sprint-ready tip over larger, vaguer items below the waterline.
           Deep dive: product-backlog_companion.md section 3 (Anatomy > Backlog Items).
     ASK   What is the ordered work? What type is each item? What value or problem does each serve? What is
           the rough estimate? Are the top items small enough to finish in one sprint?
     PRIORITY  The Rank column is the order itself (1 = next). Keep it a true total order, not ties.
     ROW HINT  A good row: a rank, a short item title, a type, the value or problem it serves (not just a
           feature name), a rough estimate (top items only), and a status. Detail the top; leave the bottom
           coarse.
     GOOD  | 1 | Save current view as a named view | story | Recurring analysts stop rebuilding filters | 5 | Ready |
     WEAK  | 1 | Views | task | (no value stated, untyped work, no estimate; nobody can pull this) | | |
     TRAP  Detailing every item to the bottom. Refining work you may never build wastes effort and
           pretends at certainty you do not have. Refine the top; keep the rest coarse. -->


| Rank | Item | Type | Value / problem it serves | Estimate | Status |
|---|---|---|---|---|---|
| {{rank}} | {{item_title}} | {{item_type}} | {{item_value}} | {{estimate}} | {{item_status}} |


## Ordering Rationale


<!-- WHAT  How the list is ordered and why: the principle behind the sequence, in a sentence or two.
     WHY   Stating the ordering principle makes the order reviewable rather than arbitrary, and it is what
           separates a real backlog from a pile sorted by whoever pushed hardest. Deep dive:
           product-backlog_companion.md section 3 (Anatomy > Ordering Rationale).
     ASK   What do you order by (value, risk, learning, dependencies)? What goes first, and why? When two
           items compete, how do you break the tie?
     GOOD  "Ordered by risk and learning first (a spike to de-risk the sharing model leads), then by value
           toward the goal, respecting dependencies (storage before sharing)."
     WEAK  "Ordered by priority." (says nothing; every backlog claims to be ordered by priority)
     TRAP  Ordering purely by raw value and ignoring dependencies and risk, so a high-value item stalls
           because the low-value work it depends on was buried. "Ordered" beats "prioritized" for exactly
           this reason. -->


{{ordering_rationale}}


## Refinement and Readiness


<!-- WHAT  How the backlog is kept refined, and what makes an item ready to pull into a sprint. Cadence,
           who refines, and a lightweight readiness bar.
     WHY   A backlog is only useful if its top is continuously kept sprint-ready; refinement is an ongoing
           team activity, not a pre-planning panic. Keep readiness a light heuristic, not a stage-gate.
           Deep dive: product-backlog_companion.md section 3 (Anatomy > Refinement and Readiness).
     ASK   How often do you refine, and who takes part? What is the lightweight bar for "ready" (clear,
           testable, small enough for one sprint)? How do you keep the backlog from bloating?
     GOOD  "Refined continuously, roughly 10% of each sprint, as a team. An item is ready when it is clear,
           has acceptance criteria, and fits in one sprint. We archive anything untouched for two quarters."
     WEAK  "We groom the backlog before each sprint." (no readiness bar, no anti-bloat practice, and
           refinement crammed into one meeting)
     TRAP  A heavy Definition of Ready enforced as a checklist bouncer. A rigid readiness gate reintroduces
           the phase-gate bureaucracy agile removed; keep it a heuristic, not a wall. -->


{{refinement_and_readiness}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 7 sections across 1 format(s), methodology Scrum/Kanban/agile, typically owned by Product Owner.