User Stories with Acceptance Criteria
Testable, not vague
BMAD user stories are sized for a single AI session and paired with acceptance criteria that cover both success and failure paths. A story without complete AC is not ready for implementation.
A BMAD user story has three required components: the user narrative (as a [user], I want [capability] so that [outcome]), the success criteria (what must be true when the story is done), and the failure criteria (what must happen when things go wrong). The failure criteria are the part most teams skip and the part that causes the most implementation surprises. An AI implementing a story with no failure handling will invent something — and it may invent it incorrectly.
Story sizing follows a rule: if a story cannot be implemented and tested in a single AI session, it must be split. This is not about AI capability — it is about verifiability. A story spanning multiple sessions cannot be reviewed at a single point. Splitting creates discrete checkpoints where a human can review the output and catch divergence from the spec before it accumulates.
Dependencies between stories must be explicit, not assumed. If story B requires the output of story A, that dependency goes in both stories' metadata. If a story depends on an external system or an infrastructure prerequisite, it cannot be scheduled until those prerequisites are resolved. The Scrum Master persona is responsible for surfacing these dependencies during backlog sequencing.
Key Concepts
- Three required components: user narrative, success criteria, failure criteria
- Failure criteria prevent silent AI assumption-making on error paths
- Single-session sizing creates discrete human review checkpoints
- Dependencies must be explicit — implicit assumptions become late-discovered blockers
- Incomplete AC means not ready for implementation — grooming must complete it