Story
A Story is the smallest unit of delivery — a specific, testable behavior the team can design, build, test, and integrate within a single sprint.
A Story is not a task. It is not a technical subtask or a component to build. It is a behavior — something the system does that is observable, testable, and valuable enough to be worth delivering.
What a Story Contains
Description
Stories are conventionally written from the perspective of whoever benefits from the behavior:
As a [who], I want [what], so that [why].
The format is a prompt for conversation, not a specification. The value is in the discussion it generates — between the Product Owner, the team, and the people who understand the need — not in the sentence itself.
Acceptance Criteria
The conditions that must be true for the Story to be done. Acceptance criteria at story level are more granular than at feature level — they define the specific behaviors, edge cases, and constraints the implementation must satisfy.
A widely-used format for writing testable acceptance criteria:
Given [context], when [action], then [expected outcome].
Acceptance criteria are written before development begins. If they cannot be written, the story is not ready.
Size
Stories are sized relative to each other — not as time estimates. Common approaches use abstract units (points, t-shirt sizes) to reflect complexity and uncertainty rather than hours.
A story too large to complete in a sprint must be split. A story too small to be worth tracking independently should be combined with related work or absorbed into another story.
Story Types
Functional Story — delivers a user-visible behavior. The most common type.
Enabler Story — invests in technical capability: infrastructure, refactoring, test coverage, security hardening, observability. Enabler Stories implement the technical parts of Enabler Features or address technical needs identified during functional development.
Spike — a time-boxed investigation into an unknown. Used when the team needs to reduce uncertainty before committing to implementation. A Spike produces knowledge, not software — its output is a decision or recommendation.
Spikes should be rare. Routine use of Spikes signals either that features are entering the sprint without sufficient refinement, or that the team is systematically underinvesting in understanding the domain.
Definition of Ready
A Story is ready to enter a sprint when:
- Acceptance criteria are written and reviewed with the Product Owner
- The Story is sized and small enough to complete in one sprint
- Dependencies are identified — either resolved or explicitly accepted with a plan
- The team has enough shared context to begin without significant re-discovery during the sprint
Pulling stories into a sprint without meeting the Definition of Ready creates mid-sprint surprises. The cost is borne in the sprint; the saving was illusory.
Definition of Done
A Story is done when it meets the team’s Definition of Done — not when the developer believes implementation is complete.
A typical Definition of Done for a mature team:
- Code written, reviewed, and merged to the main branch
- Automated tests written and passing (unit, integration, and relevant acceptance tests)
- No known regressions introduced
- Deployed to a staging or integration environment
- Acceptance criteria verified by the Product Owner or automated test
- Monitoring or observability in place if the story introduces new behavior in production
The Definition of Done is a team agreement, not an individual judgment. It should become progressively more demanding as the team’s technical capability and tooling mature.
Relationship to Features
A Story traces upward to the Feature it contributes to. The collection of Stories that implement a Feature should, when integrated, satisfy the Feature’s acceptance criteria.
A Story that cannot be connected to a Feature — or to a known technical need — is worth questioning. Work without traceability is a signal that scope is being added without portfolio awareness.