User stories and acceptance criteria: how to write them (with examples)
A user story is a short description of a requirement from the user’s point of view. It does not say how the system will be built, but who needs what and why. Acceptance criteria then define exactly when the story is done. Together they are the backbone of agile teams and a good bridge between business and development.
User story format
As a [role] I want [what] so that [why / benefit].
Example: As a sales rep I want to see the customer’s communication history in one place so that I can prepare for a meeting in a few minutes.
The “so that” part matters most. It explains the value and helps the team find the best solution.
Acceptance criteria and the Given–When–Then format
Acceptance criteria describe testable conditions. The most common format is:
Given [starting state], when [action], then [expected result].
Examples for the story above:
- Given the customer has 3 e-mails and 2 meetings, when the sales rep opens the customer card, then they see all 5 records sorted newest first.
- Given the customer has no communication, when the sales rep opens the customer card, then they see the message “No communication yet”.
The INVEST rule: how to spot a good story
- Independent – does not depend on other stories,
- Negotiable – details can be agreed with the team,
- Valuable – brings value to the user or the business,
- Estimable – the team can estimate it,
- Small – fits into one sprint,
- Testable – can be verified by acceptance criteria.
Common mistakes
- A technical task instead of a story. “Create a database table” is not a user story.
- No “why”. Without the benefit you cannot set the priority.
- Too big (an epic). Split it into smaller stories.
- Vague criteria. “It must be fast” cannot be tested; “within 2 seconds” can.
Example: user stories created in Baaito
The brief we gave Baaito:
A furniture e-shop wants customers to track their order status and change the delivery date without calling customer service. The customer signs in with e-mail, sees the order status and can pick a new delivery date from the offered slots.
Sample document
User Stories & Acceptance Criteria — Order Tracking and Delivery Rescheduling
The first pages of a real document Baaito generated from the brief above.
User Stories & Acceptance Criteria — Order Tracking and Delivery Rescheduling
Purpose and Scope
This document defines a preliminary Scrum backlog slice for a furniture e-shop capability that enables customers to track order status and change the delivery date without contacting customer service.
It is intended for backlog refinement and for defining verifiable acceptance before implementation and testing. The intended audience is the product owner, engineering team, quality assurance, and business stakeholders.
The governed scope includes:
- Customer sign-in with e-mail.
- Viewing order status.
- Selecting a new delivery date from offered delivery slots.
- Traceability between the supplied request brief, user stories, and acceptance criteria.
- Dependencies and constraints that must be refined before delivery.
The scope excludes functionality not supported by the supplied brief, including order creation, payment, cancellation, delivery-slot generation, notifications, identity verification details, customer-service workflows, and operational fulfillment processes. These exclusions require further source requirements if they are to be included.
The document is based on the supplied request brief. Detailed source requirements, approved backlog records, acceptance-test inputs, and baseline identifiers are TBD because the corresponding inputs were not supplied.
Source Requirements and Assumptions
- BR-001 — Request brief: A furniture e-shop wants customers to track their order status and change the delivery date without calling customer service. The customer signs in with e-mail, sees the order status, and can pick a new delivery date from offered slots.
- This establishes the primary customer goal and the three apparent capabilities: sign-in, order-status viewing, and delivery-date selection.
- The brief does not define detailed functional requirements, business rules, or acceptance-test evidence.
- Persona evidence: A customer is identified as the user of the capability.
- Additional personas, such as delivery operators, customer-service agents, or administrators, are TBD because no supporting input was supplied.
- User evidence: The stated need is to track order status and change the delivery date without calling customer service.
- The source does not provide research findings, usage data, or validated outcome measures. Any further benefit is TBD.
- Domain rules: The customer selects a new delivery date from offered slots.
- Rules for how slots are offered, their availability, expiration, time zones, or eligibility are TBD because no domain-rule input was supplied.
- Assumptions requiring validation:
- The customer can be identified or authenticated using an e-mail address. The authentication method and verification behavior are TBD.
- An order status is available for display. The status values and source system are TBD.
- Offered delivery slots are available to the customer. The provider and selection rules are TBD.
- Changing the delivery date can be completed through the e-shop without customer-service intervention. The update mechanism and confirmation behavior are TBD.
- Constraints and gaps: No priorities, owners, dependencies, service constraints, policy limits, error behavior, or baseline version for detailed requirements were supplied. These items are TBD and affect refinement and acceptance.
User Story Register
| Story Id | Persona | Need | Benefit | Priority | Source Requirement | Dependency | Status | Owner |
|---|---|---|---|---|---|---|---|---|
| US-001 | Customer | Sign in with e-mail | Access order-related information without calling customer service | TBD — approved prioritization input required | BR-001 | Authentication and order lookup capability TBD | Proposed; refinement required | TBD — product owner input required |
| US-002 | Customer | See the order status | Track the order without calling customer service | TBD — approved prioritization input required | BR-001 | Authenticated order-status data TBD | Proposed; refinement required | TBD — product owner input required |
| US-003 | Customer | Pick a new delivery date from offered slots | Change the delivery date without calling customer service | TBD — approved prioritization input required | BR-001 | Offered delivery slots and delivery-date update capability TBD | Proposed; refinement required | TBD — product owner input required |
Template used: User Stories & Acceptance Criteria
How to do it faster
Describe the feature in your own words or attach a BRD. Baaito turns it into user stories with Given–When–Then acceptance criteria that you can move to Jira or Azure DevOps.
FAQ
Who writes user stories? Usually the product owner or business analyst, ideally together with the team.
What is the difference between a user story and a BRD requirement? The BRD describes the objectives and scope of the whole solution. User stories break them down into small parts delivered over time.
How many acceptance criteria should a story have? Typically 3 to 7. If there are more, the story is probably too big.