User-Centered Design: 80+ Examples of User Stories with Acceptance Criteria

A user story clearly defines the user’s needs, with acceptance criteria set specific conditions for developers to meet. We’ve talked to experts and gathered the most helpful examples of user stories with acceptance criteria to help you get started.

Included in this article, you’ll find:

What Are Acceptance Criteria for a User Story?

In a user story, acceptance criteria are specific conditions that must be met for the story to be considered complete and successful. They define the scope, functionality, and quality requirements to ensure that the development team understands what they need to do for the final product to meet stakeholder expectations.

Usually, acceptance criteria appear on tickets submitted to the development team by product owners, Scrum Masters, project managers, or other stakeholders. The ticket will refer to a specific task or user story.

Hugh Smith

“When the ticket submitter outlines the acceptance criteria, it’s usually a list of specific results, and once you meet those results, you’ve completed the task,” explains Hugh Smith, a software engineer with more than a decade of experience working in Agile environments. “From a software engineer’s perspective, the acceptance criteria is almost a protection against whoever submits the ticket. It’s the protection against a constant back and forth where you think you’ve done what they told you to do, but the result doesn’t quite line up with their expectations.”

User Story vs. Acceptance Criteria

A user story is a short, simple description of a feature or requirement from the perspective of the end user. It details what the user needs and why. Acceptance criteria — also called user acceptance criteria (UAC) — are detailed conditions that specify when a user story is considered complete.

For more information on user stories, read our guides on writing user stories for software development and how to do effective user story mapping.

Rule-Oriented vs. Scenario-Oriented Acceptance Criteria

Rule-oriented acceptance criteria focus on specific rules or conditions that must always be met for the user story to be considered complete. Scenario-oriented acceptance criteria describe specific situations or use cases that demonstrate how the system should behave under certain conditions.

Scenario-oriented acceptance criteria work best for user stories that involve user interactions or end-to-end workflows. This is because they illustrate the specific steps a user will take and are meant to ensure that the feature works as intended.

In contrast, rule-oriented acceptance criteria are ideal for stories focused on validation, compliance, or technical requirements, as they define the specific conditions or rules that must be met. This approach ensures that you verify and validate both functional and nonfunctional aspects of a feature.

How to Write Acceptance Criteria

To write acceptance criteria, start with the user story. Describe what a person can do with the product. Next, consider the technical requirements (how the product provides that functionality). Finally, write the acceptance criteria (how to fulfill these requirements).

For rule-oriented acceptance criteria, focus on defining specific, consistent rules or conditions that must always be met. For scenario-oriented acceptance criteria, describe specific use cases or situations that demonstrate how the system should behave under particular conditions.

Berthot suggests following the given-when-then format for these acceptance criteria: “Given [function input or data] when [operational functionality trigger], then [criteria to achieve desired goal].”

Remember, both rule-oriented and scenario-oriented acceptance criteria should always be clear and specific, measurable, and testable.

“I would expect the writer of the ticket to give me full input and tell me what the full output should be,” says Smith.

Bryan Berthot

“A user story is not very useful unless it can be tested by the team, which is why acceptance criteria are added to give the team one or more use cases that allow the team to understand how the story may be tested,” explains Bryan Berthot, Scrum Master, Project Manager, and doctoral candidate at the University of South Florida.

Learn how to write user-centric acceptance criteria, and check out one of these free user story templates to get started.

Examples of User Stories with Acceptance Criteria by Type

Examples of acceptance criteria types include scenario-oriented and rule-oriented, as well as criteria for testing system behavior. The following examples will guide you in crafting precise and effective acceptance criteria.

Additionally, we’ve gathered examples to help you fix unclear or incomplete criteria. Use these to ensure your user stories are comprehensive and aligned with your project’s goals.

Check out our guide of more than 100 user story examples before you dive into defining acceptance criteria.

Basic Acceptance Criteria Examples

These basic examples of acceptance criteria show how a few simple sentences can effectively ensure that features meet their intended functionality, making it easier for teams to verify and validate outcomes.

Acceptance Criteria Basic Examples

Example User Stories with Acceptance Criteria

These example user stories have clear, actionable acceptance criteria that ensure precise functionality, making them valuable guides for a development team.

User Story	Acceptance Criteria
As a content creator, I want to schedule my posts in advance so that I can maintain a consistent publishing schedule.	When the user selects a date and time for the post, the post is automatically published at the scheduled time. The user can edit or cancel the scheduled post up until the time of publishing. The post must go live exactly at the scheduled time, with no delays.
As a student, I want to download course materials so that I can study offline.	When the user clicks Download on a course file, the file must download immediately to their device. The file must be in PDF format and must not exceed 10 megabytes in size. If the download fails, the user must be shown an error message with an option to retry.
As an online customer, I want to view my purchase history so that I can keep track of my orders.	When the user navigates to the Purchase History page, they must see a list of all previous orders, including the order number, date, and total amount. Each order must be clickable. The link must lead to a detailed view with itemized charges and shipping status.

Given-When-Then Acceptance Criteria Examples

The following examples of scenario-oriented acceptance criteria, provided by project management expert Bryan Berthot, follow the given-when-then format, which clearly defines the conditions, actions, and expected outcomes for each user story.

Managing Contacts Within an Application

GWT Acceptance Criteria Example 1

Concrete Porch Behind the House

GWT Acceptance Criteria Example 2

Acceptance Criteria Examples for Testing System Behavior

The following examples of rule-oriented acceptance criteria show lists of conditions or requirements that must be met — regardless of specific user scenarios — and can be used to test overall system behavior.

Acceptance Criteria for Testing System Behavior

Example of an Epic with Acceptance Criteria

The following example epic is first broken down into smaller, more manageable user stories. Then you can add specific acceptance criteria that define how each story should be implemented and validated.

Epics User Stories Acceptance Criteria Example

Bad Acceptance Criteria Examples

First and foremost, acceptance criteria should help the code developers by telling them exactly what the outcome of their work should look like or achieve. Acceptance criteria that are ambiguous, overly detailed, or contradictory will not be helpful to the developer and can lead to confusion, delays, or incorrect implementations.

Here are several examples of bad acceptance criteria and how to fix them:

Examples of Bad Acceptance Criteria (and How to Fix Them)

Problem	Example	Why It Doesn’t Work	How to Fix It
Vague or Ambiguous Language	The page should load quickly and be user-friendly.	This criterion is subjective and lacks specificity. What constitutes “quickly”? What defines “user-friendly”? Developers might interpret these terms differently, which will lead to inconsistent results. “When acceptance criteria are vague, it can end up wasting time and effort because I might have written a bunch of code that doesn’t actually solve the problem that needs solving and will have to get thrown out,” says Smith.	Define specific, measurable criteria for “quickly” and “user-friendly” that can be tested objectively.
Overly Detailed and Prescriptive	The database should be implemented using a specific NoSQL database and use a document-based storage system.	This criterion dictates how the solution should be implemented rather than what it should achieve. This limits the developer’s flexibility to choose the most appropriate technology based on the overall system requirements. “If the requestor is nitpicking, they’ll get a negative outcome because they don’t have the same expertise as the actual software engineers,” says Smith.	Focus on the desired outcome rather than prescribing a specific technology or approach.
Contradictory Criteria	The button should be green and stand out. The button should blend in with the overall page design.	These criteria conflict with each other. It’s unclear how a button can both “stand out” and “blend in.” This example would leave the developer unsure which priority to focus on. “Usually, if I notice there are contradictory criteria, I end up sending the tickets back,” says Smith. “A lot of times, though, you don’t realize there’s contradictory stuff until later in the process, which can waste time.”	Clarify the primary goal and provide criteria that do not conflict with each other.

Problem

Example

Why It Doesn’t Work

How to Fix It

Vague or Ambiguous Language

The page should load quickly and be user-friendly.

This criterion is subjective and lacks specificity. What constitutes “quickly”? What defines “user-friendly”? Developers might interpret these terms differently, which will lead to inconsistent results.

“When acceptance criteria are vague, it can end up wasting time and effort because I might have written a bunch of code that doesn’t actually solve the problem that needs solving and will have to get thrown out,” says Smith.

Define specific, measurable criteria for “quickly” and “user-friendly” that can be tested objectively.

Overly Detailed and Prescriptive

The database should be implemented using a specific NoSQL database and use a document-based storage system.

This criterion dictates how the solution should be implemented rather than what it should achieve. This limits the developer’s flexibility to choose the most appropriate technology based on the overall system requirements.

“If the requestor is nitpicking, they’ll get a negative outcome because they don’t have the same expertise as the actual software engineers,” says Smith.

Focus on the desired outcome rather than prescribing a specific technology or approach.

Contradictory Criteria

The button should be green and stand out. The button should blend in with the overall page design.

These criteria conflict with each other. It’s unclear how a button can both “stand out” and “blend in.” This example would leave the developer unsure which priority to focus on.

“Usually, if I notice there are contradictory criteria, I end up sending the tickets back,” says Smith. “A lot of times, though, you don’t realize there’s contradictory stuff until later in the process, which can waste time.”

Clarify the primary goal and provide criteria that do not conflict with each other.

Examples of User Stories with Acceptance Criteria by Use Case

The following examples of user stories with acceptance criteria are tailored to specific use cases, such as banking transactions, Scrum, Agile processes, CRM systems, APIs, and more.

Agile User Story with Acceptance Criteria Examples

These examples illustrate how well-crafted user stories and acceptance criteria can ensure that you define tasks clearly, processes run smoothly, and team members know exactly what’s expected to keep an Agile project on track.

User Story	Acceptance Criteria
As a developer, I want to merge my code changes into the main branch so that the team’s work is integrated.	When the developer opens a pull request, it must pass all automated tests before it can be merged. The pull request must be reviewed and approved by at least one other team member. If there are merge conflicts, the developer must resolve them before the merge is completed.
As a project manager, I want to assign tasks to team members so that work is distributed efficiently.	When the project manager assigns a task, the assignee is notified immediately via email and the project management tool. The task must appear in the assignee’s task list within the tool. The project manager must be able to reassign tasks if needed.
As a tester, I want to log bugs found during testing so that they can be tracked and resolved.	When the tester logs a bug, it must include a clear title, description, steps to reproduce, and severity level. The bug must be automatically assigned to the relevant developer based on the affected module. The bug must appear in the backlog within five minutes of being logged.

Scrum User Story with Acceptance Criteria Examples

These Scrum examples demonstrate how precise user stories and acceptance criteria help streamline sprint tasks, facilitate team collaboration, and ensure that project goals are met.

User Story	Acceptance Criteria
As a Scrum Master, I want to create and manage the sprint backlog so that the team can stay organized and focused on sprint goals.	The system should allow the Scrum Master to create a sprint backlog by selecting user stories from the product backlog. When a story is added to the sprint backlog, it should automatically be marked as In Progress. The system must track the total story points for the sprint and display a warning if the sprint exceeds the team’s capacity. The Scrum Master should be able to reorder stories within the sprint backlog and move them to different sprints as needed.
As a product owner, I want to prioritize the product backlog so that the most valuable features are developed first.	The system should allow the product owner to assign a priority level to each user story in the product backlog. When the priority is updated, the system should automatically reorder the backlog to reflect the new priority. The product owner should be able to filter stories by priority, status, and assigned team members. The system should also allow the product owner to add notes or comments to each story, explaining the reasoning behind the priority level.

User Story

Acceptance Criteria

As a Scrum Master, I want to create and manage the sprint backlog so that the team can stay organized and focused on sprint goals.

The system should allow the Scrum Master to create a sprint backlog by selecting user stories from the product backlog.
When a story is added to the sprint backlog, it should automatically be marked as In Progress.
The system must track the total story points for the sprint and display a warning if the sprint exceeds the team’s capacity.
The Scrum Master should be able to reorder stories within the sprint backlog and move them to different sprints as needed.

As a product owner, I want to prioritize the product backlog so that the most valuable features are developed first.

The system should allow the product owner to assign a priority level to each user story in the product backlog.
When the priority is updated, the system should automatically reorder the backlog to reflect the new priority.
The product owner should be able to filter stories by priority, status, and assigned team members.
The system should also allow the product owner to add notes or comments to each story, explaining the reasoning behind the priority level.

API Development Acceptance Criteria Example

Acceptance criteria help ensure that the endpoints of an application programming interface (API) meet specified requirements and handle requests and responses accurately. The criteria should provide clear guidelines for developers to follow.

Sidharth Ramsignhaney

Sidharth Ramsinghaney, Director of Strategy and Operations at Twilio, provides hypothetical examples of acceptance criteria for a short message service (SMS) API:

User Story: As a developer, I want to integrate SMS API into my application so that I can send automated text messages to users for notifications.

Acceptance Criteria:

The API integration should allow sending SMS to any valid phone number.
The system should log each sent message with a timestamp and status.
The integration should handle errors gracefully and provide meaningful error messages.

These acceptance criteria are clear, testable, and directly aligned with the goal of the user story. By focusing on essential functionality, how to handle errors, and measurable outcomes, they provide a strong foundation for successful implementation.

CRM User Story with Acceptance Criteria Example

Acceptance criteria in CRM development help ensure that features are implemented correctly and integrate smoothly with existing systems.

Ramsinghaney also provides an example of a user story with acceptance criteria for a CMS:

User Story: As a customer support agent, I want to use voice API to make outbound calls directly from our CRM system so that I can efficiently manage customer interactions.

Acceptance Criteria:

The CRM system should have a Call button that initiates an outbound call using Twilio’s voice API.
The call should be logged in the CRM with details such as call duration and outcome.
The system should support call recording and playback within the CRM.

These acceptance criteria outline clear, actionable tasks, such as how to initiate, log, and record a call.

Examples of User Stories with Acceptance Criteria for Bank Transactions

When creating or improving bank transaction systems, acceptance criteria are essential for defining secure, accurate, and compliant processes.

User Story	Acceptance Criteria
As a customer, I want to transfer money between my accounts so that I can manage my finances easily.	When the customer selects the Transfer option and chooses the source and destination accounts, the system should display the available balance in the source account. The transfer amount must be less than or equal to the available balance. When the customer confirms the transfer, the system should immediately deduct the amount from the source account and add it to the destination account. The transfer must be logged with a timestamp and a unique transaction ID.
As a customer, I want to schedule recurring payments so that I can automate my bill payments.	The system should allow the customer to select a frequency (e.g., weekly, monthly) and a start date for the recurring payment. When the customer sets up a recurring payment, the system should automatically process the payment on the scheduled dates without requiring further action from the customer. The customer should receive an email notification one day before each payment is processed. The system should allow the customer to modify or cancel the recurring payment at any time before the next scheduled payment.

User Story

Acceptance Criteria

As a customer, I want to transfer money between my accounts so that I can manage my finances easily.

When the customer selects the Transfer option and chooses the source and destination accounts, the system should display the available balance in the source account.
The transfer amount must be less than or equal to the available balance.
When the customer confirms the transfer, the system should immediately deduct the amount from the source account and add it to the destination account.
The transfer must be logged with a timestamp and a unique transaction ID.

As a customer, I want to schedule recurring payments so that I can automate my bill payments.

The system should allow the customer to select a frequency (e.g., weekly, monthly) and a start date for the recurring payment.
When the customer sets up a recurring payment, the system should automatically process the payment on the scheduled dates without requiring further action from the customer.
The customer should receive an email notification one day before each payment is processed.
The system should allow the customer to modify or cancel the recurring payment at any time before the next scheduled payment.

Examples of User Stories with Acceptance Criteria for Project Management Software

When creating or improving project management software, acceptance criteria provide clear expectations for developers so they can create functionality that supports seamless team collaboration and project flow.

User Story	Acceptance Criteria
As a team member, I want to log my work hours on tasks so that I can track and bill for my time accurately.	The system should allow the team member to log hours worked on each task, with an option to specify the date and time period. The logged hours must be visible to both the team member and the project manager, with the ability to edit or delete entries as needed. The system should automatically calculate total hours worked per task and display this information in the task details. Logged hours should be exportable to a timesheet for billing purposes.
As a project manager, I want to set project milestones so that I can track major deadlines.	The system should allow the project manager to create milestones by specifying a title, description, and due date. Each milestone must be linked to one or more tasks. Progress toward the milestone must automatically update based on the noted Status of each task. The system should display upcoming milestones on the project timeline and notify the project manager and relevant team members when a milestone is approaching. When all linked tasks are completed, the milestone should be automatically marked as achieved.

User Story

Acceptance Criteria

As a team member, I want to log my work hours on tasks so that I can track and bill for my time accurately.

The system should allow the team member to log hours worked on each task, with an option to specify the date and time period.
The logged hours must be visible to both the team member and the project manager, with the ability to edit or delete entries as needed.
The system should automatically calculate total hours worked per task and display this information in the task details.
Logged hours should be exportable to a timesheet for billing purposes.

As a project manager, I want to set project milestones so that I can track major deadlines.

The system should allow the project manager to create milestones by specifying a title, description, and due date.
Each milestone must be linked to one or more tasks.
Progress toward the milestone must automatically update based on the noted Status of each task.
The system should display upcoming milestones on the project timeline and notify the project manager and relevant team members when a milestone is approaching.
When all linked tasks are completed, the milestone should be automatically marked as achieved.

Downloadable PDF User Story Examples with Acceptance Criteria

User Story Examples with Acceptance Criteria

Download User Story Examples with Acceptance Criteria for Adobe PDF

For a printable roundup of three examples from this article, download this one-page list of sample user stories and their acceptance criteria. Reference this list whenever you need a quick refresher on what acceptance criteria should look like.

Effectively Define and Track User Stories with Smartsheet for Project Management

From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done.

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.

Discover a better way to streamline workflows and eliminate silos for good.

Try Smartsheet for Free Get a Free Smartsheet Demo