May 29th, 2024

What is User Story and Acceptance Criteria (Examples)


Agilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most tru... Read more

Have you ever wondered how software development teams translate your needs into real, usable features? The answer lies in two key concepts: user stories and acceptance criteria. These seemingly technical terms hold the power to bridge the gap between what you want and what gets built.

This blog post is your one-stop guide to understanding these essential elements of software development. We'll break down what they are, why they're important, and how they work together to ensure the final product meets your expectations.

So, whether you're a curious user, a budding developer, or simply someone navigating the ever-evolving world of technology, this post is for you! Get ready to unlock the secrets behind the scenes and gain valuable insights into the process of bringing your ideas to life.

What is a User Story?

 A user story is a brief description of a software feature written from the perspective of the end user. It's a common tool used in agile software development methodologies to capture the what, why, and who of a new feature.

Here's a breakdown of what a user story typically includes:

  • The user: Who is the user requesting the feature? This could be a customer, an employee, or any other person who will interact with the system.

  • The goal: What does the user want to achieve with the feature? This should be a specific and measurable objective.

  • The benefit: Why does the user want this feature? What problem does it solve or what value does it provide?

Here are some examples of user stories:

  • As a customer, I want to be able to search for products by price so that I can easily find products that fit my budget.

  • As a teacher, I want to be able to see the grades of all my students in one place so that I can easily track their progress.

  • As a librarian, I want to be able to recommend books to patrons based on their interests so that I can help them find books they will enjoy.

User stories are typically written in a simple format, such as:

  • As a [user], I want [goal] so that [benefit].

This format helps to ensure that user stories are clear, concise, and user-focused.

By using user stories, developers and product managers can gain a better understanding of the needs of their users and build software that is truly valuable to them.

How to Write User Stories?

  • 1Understand the user: Identify who are you building this feature for? What are their needs, goals, and pain points?
  • 2A common template for user stories is: As a [user persona], I want [to do something], So that [I can achieve a goal].
  • 3Keep it simple and concise: User stories should be easy to understand and written in plain language. Avoid technical jargon and focus on the user's perspective.
  • 4Focus on the value: What problem are you solving for the user? How will this feature improve their experience?
  • 5Make it testable: Define acceptance criteria that specify when the user story is considered "done." This helps ensure the team is building something that actually meets the user's needs.

Here are some additional tips for writing good user stories:

  • Keep them small and independent: This allows for greater flexibility and makes it easier to estimate the effort involved.

  • Use them as a starting point for conversation: User stories should be a starting point for discussions, not the end point.

  • Refine them as you learn more: As you learn more about your users and their needs, be prepared to adapt and refine your user stories.

By following these tips, you can write user stories that help your team focus on delivering value to users and ensure that your product meets their needs.

What is Acceptance Criteria 

Acceptance criteria are essentially a set of conditions that a product, feature, or any unit of work needs to fulfill in order to be considered complete and accepted. They serve as a crucial communication tool, establishing clear expectations for both developers and stakeholders involved in the project.

Here's a breakdown of acceptance criteria along with examples to illustrate their purpose:

What are Acceptance Criteria for?

  • 1Clarity and Alignment: They ensure everyone involved has a shared understanding of what the final product should be and how it should function. This reduces ambiguity and helps avoid misunderstandings later in the development process.
  • 2Measurable Success: By defining concrete criteria, it becomes clear when a specific task or feature is finished and meets the desired outcomes. This facilitates efficient testing and ensures the project stays on track.
  • 3Communication and Collaboration: Acceptance criteria act as a communication bridge between various stakeholders, including developers, product owners, and testers. They foster clear communication and collaboration throughout the development lifecycle.

Examples of Acceptance Criteria:

Scenario 1: E-commerce Website - User Login Feature

  • User Story: As a registered user, I want to be able to log in to the website using my email address and password so that I can access my account and manage my purchases.

  • Acceptance Criteria:

    • The login form should be accessible on the website's homepage and other relevant pages.

    • Users should be able to enter their registered email address and password.

    • Upon successful login, users should be redirected to their account dashboard.

    • The system should display an error message with clear instructions for invalid login attempts (e.g., incorrect email address or password).

    • User sessions should timeout after a period of inactivity for security reasons.

Scenario 2: Mobile App - Search Functionality

  • User Story: As a user, I want to be able to search for products by name or category so that I can easily find the items I'm interested in purchasing.
  • Acceptance Criteria:

    • The app should have a search bar prominently displayed on the main screen or easily accessible.

    • Users should be able to enter keywords or product names in the search bar.

    • The search results should be displayed in a clear and organized manner, with relevant information about each product (e.g., name, image, price).

    • The search function should offer suggestions or auto-complete options as users type their queries.

    • The app should allow users to filter search results by different criteria such as price, category, or brand.

By outlining clear and well-defined acceptance criteria, projects can benefit from improved communication, efficient development, and a higher chance of meeting user expectations.

How to Write Acceptance Criteria

Writing good acceptance criteria is essential for ensuring that everyone involved in a project is on the same page and that the final product meets expectations. Here are some key points to remember:


  • 1Acceptance criteria define the conditions that a feature or user story must meet to be considered complete.
  • 2They act as a checklist for developers and testers, ensuring all functionalities are delivered as intended.
  • 3They also serve as a communication tool, fostering a shared understanding between stakeholders, product owners, and developers.

Writing Tips:

  • 1Clarity and Conciseness: Keep it simple and straightforward. Avoid ambiguity and technical jargon. Everyone on the team, regardless of their background, should be able to understand the criteria.
  • 2Focus on Outcomes: Describe what the system should do, not how it should be achieved. This allows developers the flexibility to choose the best implementation approach.
  • 3Testability: Each criterion should be phrased in a way that allows for clear pass/fail evaluation. This is crucial for defining acceptance tests.
  • 4User Perspective: While user stories describe the "why" from a user's perspective, acceptance criteria focus on the "what" in a way that aligns with the user's goals.

Master the Art of User Stories & Acceptance Criteria: Write Clear & Effective Requirements

Build Better Products Faster: Enroll Now!

PSM I Certification

User Story Vs Acceptance Criteria

User Story
Acceptance Criteria
(1) Focus
Describes the user's needs and goals
Defines the specific conditions that must be met for the user story to be considered complete.
(2) Perspective
Written from the user's point of view.
Objective and measurable.
(3) Content
Briefly describes the desired functionality and the problem it solves for the user.
Lists detailed requirements and functionalities that need to be implemented.
(4) Structure
Typically follows the format: "As a <user type>, I want to <action> so that <benefit>."
Usually a bulleted list of specific and testable statements.
(5) Example
"As a customer, I want to be able to track my order history so that I can easily see the status of my past purchases."
The user can access their order history by logging into their account. The order history displays the date, order number, items purchased, and current status of each order. The user can filter their order history by date range or status.


User stories and acceptance criteria are powerful tools for ensuring clear communication and successful project outcomes in software development and beyond. By understanding the "why" and "what" of a feature through user stories, and defining the "how" through well-defined acceptance criteria, teams can streamline development, avoid ambiguity, and deliver products that truly meet user needs.

Furthermore, effective user stories and acceptance criteria are expressed in a concise and measurable way. Simple language, free of technical jargon, promotes better understanding across the team. Measurable criteria establish objective testing methods to verify successful implementation. Finally, these tools are dynamic, not static. As projects progress, user stories and acceptance criteria can be revisited and refined to adapt to evolving needs and ensure the project continues to deliver value to the end user.

Put Your Skills to Test With Our Free Assessment.

PSM I Assessment


While user stories are meant to be brief, some functionalities might be inherently intricate. In such cases, it's okay to have a slightly longer user story, but ensure clarity and avoid excessive detail. Break down complex functionalities into smaller, more manageable user stories if possible.


Effective acceptance criteria are specific, measurable, achievable, relevant, and time-bound (SMART). They should be clear, testable, and cover various scenarios for the user story. Ask yourself: can these criteria objectively determine if the user story is truly "done"?


While the product owner usually outlines the user story, the entire development team (including developers, testers, and the product owner) collaboratively defines the acceptance criteria. This ensures everyone is on the same page about what "done" looks like.

Yes, acceptance criteria can evolve throughout the development process. As the team gains a deeper understanding of the user story and its implementation, the criteria might need adjustments to better reflect the desired outcome. However, ensure any changes are documented and communicated clearly to all stakeholders.

There's a fine line between providing enough detail and overcomplicating the criteria. Aim to be clear and concise while capturing the essential functionalities and expected user experience. Avoid micromanaging the implementation details; let the development team have the flexibility to find the best solution within the defined criteria.


Agilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most trusted brand for digital transformations in South and South-East Asia.

WhatsApp Us

Explore the Perfect
Course for You!
Give Our Course Finder Tool a Try.

Explore Today!


Agilemania Refer and Earn
Agilemania Whatsapp