Skip to content
Product Lifecycle Templates

User Story

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

Describes a unit of work from the user’s perspective (“as a [user], I want [goal], so that [benefit]”) so a team can build and verify the right thing.

Fast reference for the User Story bundle. For the full reasoning, history, and sources, read user-stories_companion.md.

When to use

Section titled “When to use”
  • To express a unit of work from the user’s point of view, ready for a backlog.
  • When you want the work to stay a conversation, with detail emerging in refinement.
  • When a team estimates and pulls work iteratively.

When NOT to use

Section titled “When NOT to use”
  • You need the whole feature’s scope, metrics, and non-goals. Use a PRD; stories implement it.
  • You need exhaustive actor-system flows. Use a use-case specification.
  • The “done” conditions are detailed enough to deserve their own artifact. Use acceptance criteria.

Pick a variant

Section titled “Pick a variant”
  • Lean (default): a single story card (Story, Acceptance criteria, Notes). What you write most.
  • Full: adds INVEST, estimate, and dependencies. For risky, cross-team, or must-size stories. Grow lean into full by adding sections; never reorder the shared ones.

Quality rubric (INVEST, self-grade before refinement)

Section titled “Quality rubric (INVEST, self-grade before refinement)”
  • Independent: not blocked by a sibling story.
  • Negotiable: the how is open; only the need is fixed.
  • Valuable: a user or customer would recognize the value.
  • Estimable: the team can size it.
  • Small: fits in one iteration.
  • Testable: the acceptance criteria are verifiable.
  • The “so that” clause states a real benefit, not a restatement of the goal.
  • All guidance comments deleted; no placeholders remain.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. The card is the spec. Treating the one-liner as complete and skipping the conversation.
  2. UI task disguised as a story. “As a user I want a dropdown” states a solution, not a goal.
  3. No “so that.” Dropping the benefit hides whether the work is worth doing.
  4. Too big. A story that cannot fit an iteration; split it.
  5. Hidden dependencies. Unlisted blockers that surface mid-sprint.
  6. Persona theater. “As a user” everywhere, when naming the real situation would change the design (consider a job story instead).

The artifacts

Section titled “The artifacts”

user-stories_template-lean.md · ~1,000 tokens

---
title: "{{title}}"
doc_type: user-stories
size: lean
owner: "{{owner}}"
status: draft
doc_version: "{{doc_version}}"
created: "{{date}}"
updated: "{{date}}"
related_links: []
source_template: user-stories
source_template_version: 0.1.0
---


<!--
LEAN USER STORY. One story card: the statement, how you will confirm it, and any notes. The minimum
that is still genuinely useful. Use it for a single backlog item; for a set of stories, copy the card
per story. To grow a card into a fully scaffolded story, ADD sections (see
user-stories_template-full.md); never rename or reorder the ones below (the full variant is a strict
superset of this one). A story is a placeholder for a conversation, not a complete spec; keep it short
and talk.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   user-stories_companion.md for the deep reasoning), guiding questions to ASK, a GOOD and a WEAK
   example, and the TRAP to avoid.
2. Replace each {{placeholder}} with your content.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. Before you ship: self-grade against user-stories_guide.md, then DELETE every HTML comment. They are
   guidance, not content.
-->


# {{title}}


## Story


<!-- WHAT  The work as one user-centered sentence, Connextra format: "As a [type of user], I want
           [goal], so that [benefit]." Lead with who and why, not the UI.
     WHY   It forces the user, the goal, and the benefit into one line and keeps the work anchored to
           value; the "so that" clause is the test of whether the work is worth doing at all.
           Deep dive: user-stories_companion.md section 3 (Anatomy > Story).
     ASK   Whose goal is this? What outcome do they want? What real benefit does "so that" name? Is
           this an outcome, not a UI task?
     GOOD  "As a recurring analyst, I want to save my current dashboard filters as a named view, so
           that I can return to exactly this slice tomorrow without rebuilding it."
     WEAK  "As a user, I want a dropdown." (a solution in disguise; no real user, no benefit)
     TRAP  A UI task disguised as a story - stating a solution instead of the goal behind it. -->


As a {{user}}, I want {{goal}}, so that {{benefit}}.


## Acceptance criteria


<!-- WHAT  How you will know this story is done, from the user's point of view - the "Confirmation" of
           the story. Keep it short here; for richer criteria use the acceptance-criteria artifact.
     WHY   It makes the story testable (the T in INVEST) and gives "done" an objective meaning both
           sides read the same way. Deep dive: user-stories_companion.md section 3 (Anatomy >
           Acceptance criteria).
     ASK   What must be observably true for this to be done? Would a tester read it the same way you
           do? What does the unhappy path look like?
     GOOD  "I can name and save the current filters, date range, and visible columns as a view."
     WEAK  "It works well." (not observable; nothing a tester could verify)
     TRAP  No criteria at all, which leaves "done" to interpretation. -->


- {{acceptance_criterion_1}}


## Notes and open questions


<!-- WHAT  Context, links (designs, the parent epic), decisions, and anything still undecided - each
           open question with an owner and a needed-by.
     WHY   Refinement runs on surfaced unknowns; a story that hides them only looks ready.
           Deep dive: user-stories_companion.md section 3 (Anatomy > Notes and open questions).
     ASK   What is genuinely undecided? Who owns each answer, and by when? What links does a reader
           need to orient?
     GOOD  "Open: should a Team Lead set a team default, or only personal defaults? Owner: Priya,
           needed before Phase 2."
     WEAK  An empty notes block on a story that plainly has open questions (hides unknowns to look
           ready).
     TRAP  Cramming a full spec here; if it needs that much, the work is probably an epic to split. -->


{{notes}}

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).