According to the 18th State of Agile Report, poorly defined requirements remain one of the top reasons Agile projects fail to deliver expected value. And the root cause is almost always the same — user stories that sound clear in refinement but fall apart in development because nobody pinned down what "done" actually means. User stories examples with acceptance criteria that are specific, testable, and unambiguous are what separate teams that ship confidently from teams that drown in rework.
This guide gives you a ready-to-use library of real user story examples with acceptance criteria across multiple domains. You will learn the exact format that works, the most common mistakes that create ambiguity, and how AI tools in 2026 are transforming the way teams write and validate acceptance criteria — compressing what used to take hours of refinement into minutes.
What is a user story with acceptance criteria?
A user story is a short, plain-language description of a feature from the perspective of the person who will use it. It follows a simple user story template:
As a [type of user], I want [goal], so that [benefit].
Acceptance criteria are the specific, testable conditions that a user story must satisfy before it can be marked as complete. They answer one critical question: how do we know this story is done?
Together, user stories and acceptance criteria form a contract between the product owner, the development team, and stakeholders. The user story captures the why and the what. The acceptance criteria define the how we verify it. Without acceptance criteria, a user story is just a wish. With them, it becomes a deliverable.
Why acceptance criteria matter more than most teams realize
Teams that skip or rush acceptance criteria pay for it later — in bug reports, scope creep, failed sprint goals, and frustrated stakeholders. Here is what well-written acceptance criteria actually do for your team:
Eliminate ambiguity before coding starts. Developers know exactly what to build. Testers know exactly what to verify.
Reduce rework by up to 30%. When the definition of "done" is clear upfront, fewer stories bounce back from QA or stakeholder review.
Make sprint planning more predictable. Stories with clear acceptance criteria are easier to estimate because the scope is visible.
Create a shared language. Product owners, developers, and testers align on expectations without needing separate documents.
Enable automated testing. Teams using behavior-driven development (BDD) can translate acceptance criteria directly into automated test scripts using tools like Cucumber or SpecFlow.
The 2024 Scrum.org survey found that teams with well-defined acceptance criteria consistently hit their sprint goals at a higher rate than teams that relied on verbal agreements or vague bullet points.
Two acceptance criteria formats that work
There are two widely used formats for writing acceptance criteria. Both work — the right choice depends on your team's workflow and testing approach.
Rule-based format (checklist style)
This is the simplest and most common format. Each criterion is a clear, testable statement:
The system must allow users to upload files up to 25 MB.
File upload progress is displayed as a percentage.
If the upload fails, an error message appears within 3 seconds.
Supported file types: PDF, DOCX, PNG, JPG.
Best for: Teams that want fast, scannable criteria. Works well when stories are straightforward and do not require complex scenario modeling.
Scenario-based format (Given/When/Then)
Inherited from behavior-driven development, this format structures each criterion as a scenario:
Given [a precondition], When [an action occurs], Then [an expected result happens].
Example:
- Given the user has selected a file larger than 25 MB, When they click "Upload," Then the system displays an error message: "File exceeds maximum size."
Best for: Teams practicing BDD, teams with complex workflows, or stories where edge cases and conditional logic need to be explicitly captured. This format also translates directly into automated test scripts, which is a significant advantage for engineering teams investing in test automation.
Most experienced Agile coaches recommend that teams pick one format and use it consistently. Mixing formats within the same backlog creates confusion during sprint planning and refinement.
10 user story examples with acceptance criteria
Below are practical, ready-to-use user story examples with acceptance criteria across different domains. Each example includes both the rule-based and scenario-based format so you can see how the same story translates between the two.
1. E-commerce: product search
User story: As an online shopper, I want to search for products by name so that I can quickly find what I am looking for.
Acceptance criteria (rule-based):
Search results appear within 2 seconds of submitting a query.
Results display product name, image, price, and average rating.
If no results are found, the system displays "No products found" with suggested alternatives.
Search supports partial matches and common misspellings.
Acceptance criteria (Given/When/Then):
Given the user types "running shoes" in the search bar, When they press Enter, Then the system returns all products matching "running shoes" within 2 seconds.
Given the user searches for "xyznonexistent," When results load, Then the system displays "No products found" and suggests related categories.
2. SaaS platform: user registration
User story: As a new user, I want to create an account using my email so that I can access the platform's features.
Acceptance criteria (rule-based):
Registration form requires email, password, and full name.
Password must be at least 8 characters with one uppercase letter and one number.
If the email is already registered, the system shows "This email is already in use."
A confirmation email is sent within 60 seconds of registration.
The user cannot access the platform until the email is confirmed.
Acceptance criteria (Given/When/Then):
Given a visitor enters a valid email, compliant password, and full name, When they click "Sign Up," Then the system creates the account and sends a confirmation email within 60 seconds.
Given a visitor enters an email that is already registered, When they click "Sign Up," Then the system displays "This email is already in use" and does not create a duplicate account.
3. Mobile app: push notifications
User story: As a mobile app user, I want to receive push notifications about order status changes so that I stay informed without opening the app.
Acceptance criteria (rule-based):
Notifications are sent when order status changes to "Shipped," "Out for delivery," and "Delivered."
Each notification includes the order number and current status.
Users can disable notifications in app settings.
Notifications are delivered within 30 seconds of the status change.
4. Reporting dashboard: export to CSV
User story: As a team lead, I want to export my dashboard report to CSV so that I can share data with stakeholders who do not have platform access.
Acceptance criteria (rule-based):
The export button is visible on all dashboard views.
Exported CSV includes all data currently visible in the dashboard, respecting active filters.
File downloads within 10 seconds for datasets under 10,000 rows.
Column headers in the CSV match the dashboard column names exactly.
Date fields export in ISO 8601 format (YYYY-MM-DD).
5. API integration: payment processing
User story: As a developer, I want to integrate a payment gateway API so that customers can pay securely during checkout.
Acceptance criteria (Given/When/Then):
Given a customer enters valid card details and clicks "Pay," When the payment gateway processes the transaction, Then the system displays a confirmation page with a transaction ID.
Given a customer enters an expired card, When the payment is submitted, Then the system displays "Payment declined: card expired" without charging the card.
Given the payment gateway is unreachable, When the customer clicks "Pay," Then the system displays "Payment service temporarily unavailable. Please try again." and logs the error for the engineering team.
6. HR platform: leave request
User story: As an employee, I want to submit a leave request through the HR portal so that my manager can review and approve it without email threads.
Acceptance criteria (rule-based):
The leave request form includes: leave type, start date, end date, and reason (optional).
The system prevents submitting requests for dates that have already passed.
The manager receives an email and in-app notification within 5 minutes of submission.
The employee can see the request status (Pending, Approved, Rejected) on their dashboard.
If the request overlaps with another approved leave, the system shows a warning but allows submission.
7. Content management: article publishing
User story: As a content editor, I want to schedule articles for future publication so that content goes live at optimal times without manual intervention.
Acceptance criteria (Given/When/Then):
Given the editor selects a future date and time and clicks "Schedule," When the scheduled time arrives, Then the article is published automatically and appears on the public site.
Given the editor schedules an article, When they view the article list, Then the article shows status "Scheduled" with the planned publication date.
Given the editor wants to cancel a scheduled article, When they click "Unschedule," Then the article reverts to "Draft" status and is not published.
8. Project management: task assignment
User story: As a project manager, I want to assign tasks to team members with due dates so that everyone knows their responsibilities and deadlines.
Acceptance criteria (rule-based):
Tasks can be assigned to one or more team members.
Each task requires a title, assignee, and due date. Description is optional.
Assigned team members receive a notification within 2 minutes.
Overdue tasks are highlighted in red on the project board.
Tasks can be reassigned without losing comment history.
9. Healthcare: patient appointment booking
User story: As a patient, I want to book an appointment with my doctor online so that I do not have to call the clinic during working hours.
Acceptance criteria (rule-based):
The system displays available time slots for the selected doctor and date.
Patients can only book appointments up to 30 days in advance.
A confirmation email and SMS are sent immediately after booking.
Patients can cancel or reschedule up to 24 hours before the appointment.
Double booking the same time slot is prevented at the system level.
10. AI-assisted backlog: auto-generated acceptance criteria
User story: As a product owner, I want the system to suggest acceptance criteria based on my user story text so that I can speed up refinement sessions.
Acceptance criteria (Given/When/Then):
Given the product owner enters a user story in the standard format, When they click "Generate Criteria," Then the system produces 3–5 suggested acceptance criteria within 10 seconds.
Given the generated criteria are displayed, When the product owner edits or deletes a suggestion, Then the changes are saved immediately.
Given the user story is vague or incomplete, When criteria generation is triggered, Then the system displays a prompt asking the product owner to add more detail before generating suggestions.
Common mistakes that make acceptance criteria useless
Even experienced teams fall into patterns that turn acceptance criteria from a useful tool into busywork. Here are the mistakes that cause the most damage — and how to fix them.
Too vague to test
Bad: "The page should load quickly."
Good: "The page loads within 2 seconds on a 4G connection with no cached assets."
If a tester cannot write a pass/fail test from the criterion, it is not specific enough.
Too technical for stakeholders
Bad: "The API returns a 200 status code with a JSON payload containing a valid JWT token."
Good: "After successful login, the user is redirected to the dashboard and can access all features without logging in again for 24 hours."
Acceptance criteria should be understandable by anyone in the room during refinement — not just developers.
Too many criteria per story
If a single user story has 15+ acceptance criteria, the story is almost certainly too large. Break it down. A good rule of thumb from experienced Scrum coaches is 3–7 acceptance criteria per story. More than that signals the story needs splitting during sprint planning.
Missing edge cases and error states
Teams often write criteria for the "happy path" and forget what happens when things go wrong. Every user story should include at least one criterion covering an error state, invalid input, or boundary condition.
Confusing acceptance criteria with the definition of done
Acceptance criteria are story-specific — they describe what this particular story must do. The definition of done is team-wide — it describes the quality standard every story must meet (code reviewed, tests passing, documentation updated). These are complementary, not interchangeable.
How AI is transforming the way teams write user stories in 2026
The biggest shift in how teams handle user stories and acceptance criteria is happening right now, driven by AI tools that are fundamentally changing refinement sessions.
AI-generated acceptance criteria are becoming standard practice. Tools like Jira's AI features, StoriesOnBoard AI, and standalone generators can now take a user story and produce well-structured acceptance criteria in seconds. Product managers who previously spent 5–15 hours per week writing user stories and acceptance criteria are compressing that work dramatically.
But AI generation alone is not enough. The best-performing teams in 2026 use AI as a drafting tool, not a replacement for human judgment. The pattern that works is:
The product owner writes or dictates the user story.
AI generates initial acceptance criteria.
The team reviews, edits, and adds domain-specific edge cases during refinement.
AI validates that the criteria are testable and non-overlapping.
This hybrid approach cuts refinement time while maintaining quality — and it is exactly the kind of workflow evolution that organizations adopting AI-augmented Agile need to master.
FixAgile, an Agile training and implementation framework designed for the age of AI, specifically trains teams on integrating AI into their refinement workflows. Rather than treating AI as a bolt-on tool, FixAgile's training programs help product owners and Scrum Masters build repeatable processes where AI accelerates story writing, criteria validation, and backlog grooming — without losing the human collaboration that makes Agile work.
The teams that will struggle most in the next two years are those that either ignore AI entirely or blindly accept AI-generated criteria without team review. The competitive advantage goes to organizations that build structured, AI-augmented refinement processes — and that requires deliberate training and coaching.
How to write acceptance criteria that survive sprint planning
Sprint planning is where weak acceptance criteria get exposed. Here is a practical checklist that product owners and Scrum Masters can use to validate criteria before committing stories to a sprint.
The acceptance criteria readiness checklist:
Is each criterion independently testable? A tester should be able to verify it with a clear pass or fail.
Is the scope bounded? The criteria should make it impossible to expand the story mid-sprint without adding a new story.
Are error states covered? At least one criterion should describe what happens when something goes wrong.
Is the language non-technical? Every stakeholder in the refinement session should understand every criterion.
Are there 3–7 criteria? Fewer suggests missing requirements. More suggests the story needs splitting.
Does each criterion have a measurable outcome? "Fast," "user-friendly," and "intuitive" are not measurable. Seconds, clicks, and error rates are.
Has the team discussed edge cases? Even if you do not write criteria for every edge case, the team should have talked through the major ones.
This checklist alone can improve sprint goal completion rates significantly. Teams that use a structured validation process for acceptance criteria before sprint planning report fewer mid-sprint scope changes and more predictable velocity.
User story template you can copy today
Here is a clean, reusable user story template with acceptance criteria that you can adapt for any domain:
User story:
As a [specific user role], I want [specific action or feature] so that [measurable benefit or outcome].
Acceptance criteria (rule-based):
[Specific, testable condition 1]
[Specific, testable condition 2]
[Error/edge case condition]
[Performance or timing condition, if applicable]
Acceptance criteria (Given/When/Then):
Given [precondition], When [action], Then [expected outcome].
Given [error precondition], When [action], Then [error handling outcome].
Tips for using this template:
Always include the "so that" clause — it forces you to articulate value and helps the team prioritize.
Write the acceptance criteria before estimation. If you cannot define what "done" looks like, you cannot estimate it.
Review criteria with the full team during refinement, not in isolation.
Make your user stories actually work
Writing user stories with acceptance criteria is not a bureaucratic exercise — it is the single most impactful practice for reducing rework, improving sprint predictability, and aligning your entire team around what matters. The examples and formats in this guide give you a practical starting point, but the real skill is building the habit of writing testable, specific, and bounded criteria for every story that enters your backlog.
As AI tools continue to accelerate how teams draft and validate acceptance criteria, the teams that thrive will be those that combine AI efficiency with strong Agile fundamentals. If your team struggles with vague requirements, unpredictable sprints, or acceptance criteria that do not hold up in development, this is exactly what FixAgile's training programs are built to solve — practical, hands-on coaching that helps teams write better stories, run tighter refinements, and integrate AI into their workflows without losing what makes Agile effective.
