The familiar user-story sentence is only a prompt for conversation. A delivery-ready story also needs context, boundaries, examples, data and permission rules, failure behavior, and acceptance criteria that a reviewer can observe. The goal is shared understanding, not perfect ticket prose.
Decision snapshot
| Decision | Practical approach | Watch for |
|---|---|---|
| Keep one outcome | A story should describe a coherent slice of user value. | Tickets grouped by technical layer are difficult to accept as user behavior. |
| Use concrete examples | Show representative inputs, states, and expected outcomes. | Abstract rules often hide disagreements until testing. |
| Test boundaries | Cover permissions, invalid input, unavailable dependencies, and repeat actions. | Happy-path-only criteria shift decisions to the end of development. |
Start from the workflow event
Name who is acting, what triggered the action, the goal, current context, and why the outcome matters. Link to research or the relevant requirement.
Choose a vertical slice
Include enough interface, logic, data, and feedback to complete one observable outcome. Split by workflow variation or rule, not simply frontend versus backend.
Write acceptance criteria as examples
Use clear given, when, then statements or concise rules for successful, empty, invalid, unauthorized, duplicate, timeout, and recovery states.
Add nonfunctional constraints deliberately
Include accessibility, security, privacy, audit, performance, localization, and analytics only where they materially affect acceptance. Reference shared standards instead of duplicating them.
Review before commitment
Have product, design, engineering, test, and operations identify ambiguity, dependencies, test data, rollout concerns, and missing decisions before estimating.
Action checklist
- Actor, trigger, goal, and value are specific
- Story is a demonstrable vertical slice
- Business rules and representative examples are attached
- Permission, invalid, duplicate, failure, and recovery states are covered
- Accessibility, privacy, security, and measurement needs are referenced
- Acceptance can be demonstrated without interpreting subjective adjectives
Working worksheet
Record these fields in the same working document so the decision can be reviewed and handed off:
- Actor and triggering context
- Desired outcome and supporting evidence
- In-scope behavior and exclusions
- Examples: initial state, action, expected result
- Dependencies, constraints, test data, analytics, and rollout note
Common failure patterns
- Writing stories for internal components with no observable outcome
- Packing several unrelated workflows into one ticket because they share a screen
- Treating acceptance criteria as an exhaustive test suite or technical implementation plan
Connect this work
A ticket should trace to a broader outcome and decision. Read anchor stories in product context.
Good slicing makes priority tradeoffs practical. Read split work around the release outcome.
Onboarding exposes permissions, empty states, interruption, and recovery. Read apply criteria to first-run states.