Skip to content
Product Lifecycle Templates

Sprint Backlog

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

The Developers’ living plan for a single Sprint: the Sprint Goal (why), the Product Backlog items selected for it (what), and the plan for delivering them (how). A forecast, not a contract; the one thing committed to is the Sprint Goal. Drawn as a Sprint-sized subset from the product backlog.

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

When to use

Section titled “When to use”
  • Your team runs time-boxed Sprints and needs one place to hold this Sprint’s goal, selected items, and plan.
  • You are at Sprint Planning and need to turn a slice of the product backlog into a forecast the Developers own.
  • You want the day-to-day work visible and re-plannable against a single objective.

When NOT to use

Section titled “When NOT to use”
  • You do not run Sprints. A Kanban or continuous-flow team has no Sprint Backlog; pull work against WIP limits on a flow board and forecast with cycle time instead.
  • You need the ordered whole-product list. That is the product backlog (strategic, ongoing); the Sprint Backlog is one Sprint’s forecast drawn from it.
  • You want a management status report. The Sprint Backlog is the Developers’ working plan, not a report for stakeholders. A status update is a different artifact.
  • You are recording a standing quality bar. “Done” criteria that apply to every increment are a Definition of Done, not a Sprint Backlog.

Sprint backlog or product backlog? (the question people actually have)

Section titled “Sprint backlog or product backlog? (the question people actually have)”
Sprint Backlog Product Backlog
Scope One Sprint The whole product
Owner The Developers The Product Owner
Commitment The Sprint Goal The Product Goal
Lifespan One Sprint, then archived Ongoing, emergent
Is A forecast of this Sprint’s work The ordered list all work is drawn from

The Sprint Backlog is a Sprint-sized subset drawn from the top of the product backlog; it never duplicates or bypasses it.

Pick a variant

Section titled “Pick a variant”
  • Lean (default): Sprint Goal, Selected Items, Delivery Plan. The Scrum Guide’s three-part composition (why, what, how). For most settled teams this is the whole artifact, kept live on a board.
  • Full: adds Capacity and Forecast, Progress and Tracking, and Risks and Carry-over. Use it when the team is still calibrating its capacity, the forecast and tracking must be legible beyond the team, or the Sprint carries real dependencies and carry-over risk.

Grow lean into full by adding sections; never reorder the shared ones. The scaling signal is planning weight, not Sprint length.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”
  • There is one Sprint Goal, written as an objective (an outcome), not a list of items.
  • The goal was selected first, and the items were chosen to serve it.
  • The selected items are a Sprint-sized subset drawn from the product backlog, each with an id, an estimate, and a daily-updatable status.
  • The plan is actionable and inspectable daily, not a fixed task schedule to defend.
  • The document reads as a forecast, and the only thing framed as a commitment is the Sprint Goal.
  • The artifact is clearly the Developers’, not edited by the Product Owner or a manager.
  • (Full) Capacity is stated with a buffer, and velocity is used as a measure, not a target.
  • (Full) Tracking is something the team keeps current for its own re-planning, not a manager report.
  • (Full) Carry-over returns unfinished work to the product backlog, not automatically to next Sprint.
  • It is kept updated through the Sprint, not frozen at planning.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. The Product Owner’s list. A Sprint Backlog dictated or edited by the PO or a manager. The Developers own the plan; the PO orders the product backlog and proposes the goal.
  2. The forecast as a contract. Treating the selected items as a promise to ship exactly those, which punishes the team for learning. Commit to the Sprint Goal; forecast the items.
  3. Velocity as a target. Pushing velocity up as a goal, which inflates estimates and erodes quality. Velocity is a measure, not a target.
  4. The goalless sprint. A list of unrelated items with no Sprint Goal, so nothing coheres and there is no basis to renegotiate scope.
  5. Over-filling the sprint. Planning to 100% of capacity with no buffer, so any surprise blows the Sprint.
  6. The frozen plan. Written once at planning and never updated, so it stops being the real-time picture it is meant to be.

No paired skill (yet)

Section titled “No paired skill (yet)”

There is no deliver-sprint-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”

sprint-backlog_template-lean.md · ~1,450 tokens

---
title: "{{sprint_name}} Sprint Backlog"
sprint: "{{sprint_name}}"
team: "{{team_name}}"
dates: "{{start_date}} to {{end_date}}"
status: "{{status}}"
doc_type: sprint-backlog
size: lean
source_template: sprint-backlog
source_template_version: 0.1.0
---


<!--
LEAN SPRINT BACKLOG. The whole artifact for most sprints: the Sprint Goal (why), the items you selected
(what), and the plan for delivering them (how). To grow it into a full sprint backlog (see
sprint-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 SPRINT BACKLOG IS THE DEVELOPERS' LIVING PLAN, NOT A CONTRACT. It is "by and for the Developers": the
Product Owner orders the product backlog and proposes the goal, but the Developers own this plan. It is a
FORECAST, not a promise to ship exactly these items; the one thing you commit to is the SPRINT GOAL, which
fixes the objective while leaving the exact work flexible. Keep it updated throughout the sprint. See
sprint-backlog_companion.md sections 1 and 6.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   sprint-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 legend and ROW HINT says what a
   good row contains.
2. Replace each {{placeholder}} with your content. Select the goal first, then the items that serve it.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. This is a living document, updated as you learn, but before you first share it: self-grade against
   sprint-backlog_guide.md, then DELETE every HTML comment. They are guidance, not content.
-->


# {{sprint_name}} Sprint Backlog


## Sprint Goal


<!-- WHAT  The single objective for this sprint: the one outcome that makes the sprint worthwhile, stated
           as a goal, not a list of items.
     WHY   The Sprint Goal is the sprint's "why" and the thing you actually commit to. It gives the work
           coherence and it is the source of your flexibility: because you commit to the objective, the
           exact items can change as you learn. Select it FIRST, then the items that serve it. Deep dive:
           sprint-backlog_companion.md section 3 (Anatomy > Sprint Goal).
     ASK   What is the one objective of this sprint? Why is it worth doing now? How will we know we met
           it? Could a reasonable person tell whether we achieved it?
     GOOD  "A Recurring Analyst can save the current dashboard state as a named view and reopen it, in one
           click, across sessions."
     WEAK  "Finish SV-1, SV-2, and SV-3." (a list of items, not an objective; nothing to renegotiate scope
           against)
     TRAP  Writing the goal as the item list. If the goal is just "do these tickets", you have no basis to
           drop or swap an item mid-sprint, which is the whole point of committing to a goal. -->


{{sprint_goal}}


## Selected Items


<!-- WHAT  The Product Backlog items the Developers pulled into this sprint to meet the goal, ordered by
           their contribution to it. Drawn from the top of the product backlog, not invented here.
     WHY   These are your forecast of what will get done, informed by the goal and your capacity. They are
           a subset of the product backlog, not a copy of it. Deep dive: sprint-backlog_companion.md
           section 3 (Anatomy > Selected Items).
     ASK   Which product-backlog items serve the goal? Are they small enough to finish this sprint? Is each
           one clear enough to start? Who pulls each (or does the team pull)?
     PRIORITY  Order the rows by contribution to the Sprint Goal (top = do first). This is a forecast, not
           a ranked contract.
     ROW HINT  A good row: the item's id (from the product backlog), a short title, its estimate, and a
           status you can update daily.
     GOOD  | SV-1 | Persist a saved view (storage) | 5 | In progress |
     WEAK  | | "Views stuff" | | (no id, no estimate, no status; cannot be tracked or traced to the backlog)
     TRAP  Copying the whole product backlog in, or inventing items here that are not in it. The sprint
           backlog draws a sprint-sized subset from the product backlog; it does not duplicate or bypass
           it. -->


| Item | Title | Estimate | Status |
|---|---|---|---|
| {{item_id}} | {{item_title}} | {{estimate}} | {{item_status}} |


## Delivery Plan


<!-- WHAT  The actionable plan for turning the selected items into a done increment: the "how", at enough
           detail to inspect progress every day. Often the work is broken into tasks.
     WHY   The plan is what makes daily progress visible and re-plannable. The Scrum Guide requires only
           that it be "actionable" and detailed enough for the Daily Scrum; it prescribes no task format,
           and the plan is meant to change as you learn. Deep dive: sprint-backlog_companion.md section 3
           (Anatomy > Delivery Plan).
     ASK   What tasks does each item break into? What is the sequence and who is doing what? What must be
           true for an item to be "done" (does it meet the Definition of Done)? What do we update daily?
     GOOD  "SV-1: migration for the saved_view table (done), repository + API (in progress), tests. SV-2:
           capture-current-state UI, save endpoint, acceptance tests. Board updated at the Daily Scrum;
           each item is done only when it meets the team DoD."
     WEAK  "Build the features." (no tasks, no sequence, nothing to inspect day to day)
     TRAP  Over-specifying the plan up front. It is the part most certain to change, so plan enough to
           see movement, not a fixed task schedule you will spend the sprint defending. -->


{{delivery_plan}}

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: 6 sections across 1 format(s), methodology Scrum, typically owned by Developers.