Stories

Table of Contents

Summary

In agile practice, a user story is the unit of planning: a short statement of one outcome valued by someone, deliberately small enough to finish within an iteration, with acceptance criteria that make "done" checkable. Stories let a team plan in outcomes rather than activities, and grow into epics when several of them arc toward one larger capability.

In ORE Studio, a story is the unit of sprint-level intent: one coherent outcome a sprint commits to, born from a capture promoted out of the product backlog and decomposed into one-PR-sized tasks. Stories are grouped in the sprint backlog by theme, optionally clustered into epics, sized by their task count, and live in exactly one sprint — unfinished work continues through an explicit successor story, never by dragging the story along.

Detail

What a story is

A story captures one outcome, phrased from the point of view of what it delivers, with explicit acceptance criteria. It is the level at which the sprint plans and reports: the sprint page's * Stories tables list stories, the sprint health charts count story transitions, and the retrospective talks in story outcomes.

Stories come from captures: during sprint planning a chosen capture is moved into the sprint and its #+type: flips from capture to story, preserving its :ID:. A story's own content contract — blurb, * Goal, * Status, * Acceptance, * Tasks, * Decisions, * Out of scope — is defined in Document types.

Themes and epics

Every story sits under one of the six sprint themes (Product, Tooling, Agile, LLMs, Documentation, Infrastructure) in the sprint's * Stories section. Within a theme, an epic is an optional sub-grouping for a cluster of two or more stories that form a coherent multi-story arc toward a single named capability; it carries a one-paragraph description of what the arc is working toward. Stories that belong to no epic sit directly in the theme's table.

Sizing

Stories are sized by their tasks: a story with more than ~10 tasks is usually two stories. The converse also applies — a task whose work is genuinely one outcome but too large for one PR should be promoted to a story whose tasks are the natural decomposition.

Ready and done

A story is ready to leave BACKLOG when its Goal, Acceptance, and at least the first few Tasks are filled, and its parent sprint exists.

A story is done when every task is DONE / ABANDONED / carried, and the Acceptance has been re-read and still holds.

Cross-sprint continuations

A story belongs to exactly one sprint. When work doesn't fit:

  1. Close the story in sprint N as DONE reflecting what landed.
  2. Tasks that didn't make it are recorded in the predecessor's * Out of scope or moved to the successor's BACKLOG.
  3. Create a successor story in sprint N+1 with:
    • A fresh :ID:; slug suffixed _continued, _phase_2, or similar.
    • #+predecessor: frontmatter pointing at the prior story.
    • A Continued from: line under the parent-sprint link.
  4. Update the predecessor:
    • #+successor: frontmatter pointing forward.
    • Continued in: note in * Decisions.

Audit verifies the bidirectional link. The same pattern applies across version boundaries.

See also

Emacs 29.1 (Org mode 9.6.6)