A user story is a conversation starter
A common format is “As a [user], I want [capability], so that [benefit].” The format is useful because it keeps the user and purpose visible, but the real quality comes from the conversation around it.
Example
As a returning customer, I want to pause my subscription so I can temporarily stop deliveries without cancelling my account.
Acceptance criteria
Acceptance criteria turn a vague expectation into observable behavior. They should help the team, tester and stakeholder reach the same conclusion about whether the item is complete.
| Question | Practical answer |
|---|---|
| Scenario | Active subscription |
| Action | Customer chooses Pause |
| Expected | Subscription enters paused state and future billing is handled according to the agreed rule |
| Exception | Customer cannot pause when an order is already locked for fulfillment |
INVEST is a useful conversation aid
Independent, Negotiable, Valuable, Estimable, Small and Testable are commonly used qualities for user stories. Treat them as prompts for discussion rather than a bureaucratic scorecard.
Stories support conversation; criteria support verification
A user story keeps the user and reason visible. Acceptance criteria make the expected behavior concrete enough for developers, QA and stakeholders to discuss the same thing.
Think through edge cases early
Happy path: customer selects a store and sees available pickup details.
Edge case: the store becomes unavailable before checkout confirmation.
Failure: the pickup location service cannot respond.
These cases are not “extra detail.” They are often where customer-facing defects appear. Good acceptance criteria make the conversation happen before the defect does.
Write one story for subscription cancellation with six acceptance criteria: normal cancellation, already-cancelled subscription, payment issue, future renewal, confirmation, and customer notification.