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.