Agile basics
User story vs acceptance criteria
A user story explains why a capability matters. Acceptance criteria explain how the team will know that capability is complete. They are complementary, not interchangeable.
The difference at a glance
| User story | Acceptance criteria | |
|---|---|---|
| Primary purpose | Frame the user need and outcome. | Define the testable boundaries of done. |
| Typical format | As a [user], I want [goal], so that [value]. | Given [context], when [action], then [result]. |
| Audience | The whole delivery team and stakeholders. | Product, engineering and QA during delivery. |
| Level of detail | Concise and outcome-focused. | Specific enough to implement and test. |
One example, side by side
User story
As a returning customer, I want to save more than one delivery address, so that checkout is faster for different locations.
Acceptance criteria
Scenario: Add a second delivery address Given a signed-in customer already has one saved address When they add a valid new address Then it is added to their address book And they can select it during checkout Scenario: Keep the address list usable Given a customer has saved addresses When they remove an address that is not the default Then it is no longer available for checkout And the default address remains unchanged
How to use both in refinement
- Start with the story and agree on the user and the value.
- Ask what must happen for that value to be delivered.
- Write criteria for the important success, validation and permission paths.
- Review the examples with QA before the work enters a sprint.
A story should not become a technical specification. If a detail is only about implementation, keep it in engineering notes unless it changes the user outcome, compliance requirement or agreed constraint.
Write both from a short brief
CriteriaPilot can create an editable user story or acceptance-criteria draft from the same feature description.
Draft a requirement