Acceptance Criteria Examples: sample scenarios for user stories
Acceptance criteria describe the observable conditions a user story must satisfy. Good criteria let product, engineering, and QA agree on behavior before implementation.
Use the examples below as patterns. They are illustrative product rules, not requirements that automatically apply to your product.
Two useful formats
Given, When, Then describes a scenario: the starting state, the user action, and the expected result.
A checklist describes rules the finished story must satisfy. Use it when separate scenarios would repeat the same context.
Both formats need clear outcomes. “The experience should be intuitive” gives a reviewer no reliable pass/fail decision.
Example 1: sign in
Story: As a returning customer, I want to sign in so I can access my account.
Given I am on the sign-in page
When I enter a registered email and valid password
Then I reach my account dashboard.
Given I am on the sign-in page
When I enter an incorrect password
Then I remain on the page and see an error.
Given I am already signed in
When I open the sign-in page
Then I reach my account dashboard without entering credentials again.
This example assumes a signed-in visitor goes directly to the dashboard. If your product supports account switching instead, agree on that behavior and write a separate scenario.
Example 2: save a payment method
Story: As a returning buyer, I want to save a payment method so a later purchase takes fewer steps.
Checklist:
- A valid payment method can be saved for the current account.
- An invalid method is not saved and produces an actionable error.
- Saved methods are available only to the authorized account.
- A buyer can remove a saved method.
- The team decides what happens if a removed method is needed for an existing subscription.
Avoid adding rules about specific payment processing or storage that have not been agreed with engineering.
Example 3: export a report
Story: As a workspace member, I want to export the selected reporting period so I can prepare a stakeholder update.
Given I have export permission
When I export a period with accessible records
Then the CSV includes only records I can access.
Given the selected period has no matching records
When I request an export
Then I see an explanation rather than a misleading report.
Given I lack export permission
When I request an export
Then no export is generated.
Confirm file format, supported size, and retry behavior as separate decisions.
Example 4: change a workspace role
Story: As a workspace administrator, I want to change a member's role so access reflects their responsibilities.
- An administrator can select an allowed role.
- A member without administration permission cannot change roles.
- The updated access rules apply after the change.
- The team defines how existing sessions reflect revoked access.
- Rules about the final administrator remain an explicit decision.
This pattern catches cases a happy-path-only story would miss.
A review checklist
Ask whether each criterion describes observable behavior, uses an agreed rule, and can be evaluated without guessing.
Check the happy path, invalid input, permission boundaries, empty states, and failures. Add performance or accessibility conditions where they matter, using agreed thresholds instead of invented numbers.
Link to supporting research or policy when the rule needs traceability.
Acceptance criteria versus Definition of Done
Acceptance criteria are specific to the story. The Definition of Done describes quality expectations shared across the team's work, such as required review and testing.
A story can satisfy its functional criteria while still failing the team's completion standards. Keep both visible.
Use AI to identify gaps
Use the user story generator to draft stories and criteria, then review the proposed rules.
Draft acceptance criteria for this story.
Separate confirmed rules from unresolved decisions.
Cover successful, invalid, permission, empty, and failure scenarios.
Do not invent business rules or measurable thresholds.
List questions that must be resolved before implementation.
PM Prompt helps structure the review. Your team confirms the behavior before the criteria become a commitment.
Frequently asked questions
What are acceptance criteria?
They are conditions that define acceptable behavior for a particular story or feature.
What are the different types of acceptance criteria?
Scenario-based criteria describe interactions and outcomes. Checklist criteria describe a set of required conditions. Either can include functional and relevant quality requirements.
How are acceptance criteria different from Definition of Done?
Criteria define the story's behavior. Definition of Done defines shared standards for completed work.
When should acceptance criteria be written?
Write and review them before implementation, then update them when an agreed requirement changes.
References: GeeksforGeeks on acceptance criteria and Ascendle's user-story guide.