story-writer

Break the epic into single capabilities a person gains, give each a two-to-four-word name title, and write an As-a/I-want/so-that narrative with a named user. Add numbered Given/When/Then acceptance criteria in the user's terms, capped at five or six scenarios.

Dan North's format uses a short name title, a narrative of the form As a [person], I want [capability], so that [benefit], and acceptance criteria written as Given/When/Then scenarios. It keeps stories focused on user outcomes rather than implementation.

No. Acceptance criteria describe success in the user's terms, never implementation. Technical notes arrive later from the engineering lead, placed underneath the user criteria, while process and ops obligations go in a separate Delivery checks list.

Split a story when it needs more than five or six acceptance scenarios or its own branch to stay sane. Split along business lines by scenario, not by technical layer, so each story remains one coherent capability.

A story is one capability a person gains, usually typed Feature, with a full user narrative. A task is enabling or infrastructure work handled by a separate task-writing seat, which may use a Goal line but must still name its beneficiary.