Acceptance Criteria for User Stories: A Practical Guide

Acceptance criteria for user stories define the conditions a story must meet before it can be accepted as complete. They help product owners, developers, QA testers, and stakeholders understand what the user should be able to do, what the system should return, and how success will be tested.

A user story explains the user’s goal. Acceptance criteria explain how the team will know that goal has been delivered correctly.

For the full definition and wider context, start with our guide on what acceptance criteria are. This article focuses specifically on how acceptance criteria work inside user stories.

What are acceptance criteria for user stories?

Acceptance criteria are the testable conditions attached to a user story. They remove ambiguity by describing the expected behaviour, rules, edge cases, and outcomes.

A common user story format is:

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

Example:

As a customer, I want to reset my password, so that I can regain access to my account.

The acceptance criteria then define what must happen for that story to be accepted:

1. The user can request a password reset with a registered email.
2. The system sends a reset link to the registered email.
3. The reset link expires after 30 minutes.
4. The user sees a safe error message if the email is not registered.

This gives the team a shared understanding of what to build and test.

How acceptance criteria relate to the user story

A user story should stay focused on the user need. Acceptance criteria add the detail needed to make the story buildable and testable.

Think of it this way:

1. User story: What the user wants and why.
2. Acceptance criteria: What must be true before the story is complete.
3. Test cases: How QA will verify the criteria.
4. Definition of done: The wider quality standard the team applies to all work.

For example, “As an admin, I want to invite users” is the story. The acceptance criteria explain whether the invite is sent by email, whether the link expires, what role the invited user gets, and what happens if the email already exists.

When should acceptance criteria be written?

Acceptance criteria should be written before the user story enters development. In Agile and Scrum teams, this often happens during backlog refinement or sprint planning.

The product owner, business analyst, or product manager may draft them first, but developers and QA testers should review them before work starts. This helps identify unclear rules, missing edge cases, technical constraints, and testing gaps early.

A story should not move into a sprint if the team does not understand what success looks like.

How to write acceptance criteria for user stories

Good user story acceptance criteria should be clear, specific, and testable. They should describe expected behaviour without forcing a specific technical solution too early.

A simple process:

1. Start with the user story.
2. Identify the main successful outcome.
3. Add important business rules.
4. Include failure states and edge cases.
5. Make each condition testable as pass or fail.
6. Review the criteria with product, development, and QA.
7. Split the story if the criteria become too large.

For more worked formats and scenarios, explore these practical acceptance criteria examples.

User story acceptance criteria examples

1. Password reset user story

User story:

As a user, I want to reset my password, so that I can regain access to my account.

Acceptance criteria:

Given the user is on the login page

When they request a password reset using a registered email

Then the system sends a reset link to that email

Checklist version:

1. User can request a reset link.
2. Reset link is sent to the registered email.
3. Link expires after 30 minutes.
4. User can set a new password that meets security rules.
5. Unregistered emails show a safe generic message.

2. Task filter user story

User story:

As a project manager, I want to filter tasks by status, so that I can quickly review work progress.

Acceptance criteria:

Given the project manager is viewing the task list

When they select a status filter

Then only tasks with that status are displayed

Checklist version:

1. Tasks can be filtered by pending, in progress, and completed.
2. Filtered results update immediately.
3. User can clear the selected filter.
4. Empty results show a helpful message.

3. Invoice download user story

User story:

As a customer, I want to download my invoice, so that I can keep a record of my payment.

Acceptance criteria:

Given the customer has a paid invoice

When they click Download PDF

Then the invoice downloads in PDF format

Checklist version:

1. Paid invoices can be downloaded.
2. File downloads as a PDF.
3. File name includes the invoice number.
4. Only authorised users can download invoices.
5. Failed downloads show an error message.

4. Admin invitation user story

User story:

As an admin, I want to invite team members, so that they can access the platform.

Acceptance criteria:

Given the admin enters a valid email address

When they send an invitation

Then the invited user receives an email invite

Checklist version:

1. Admins can invite users by email.
2. Invite link expires after 7 days.
3. Existing users cannot receive duplicate invites.
4. Admin can assign a role before sending the invite.
5. Invitation status is visible in the admin panel.

5. Booking user story

User story:

As a client, I want to book an available time slot, so that I can schedule a consultation.

Acceptance criteria:

Given the client selects an available time slot

When they confirm the booking

Then the system reserves the slot and sends a confirmation email

Checklist version:

1. Only available slots can be selected.
2. Booked slots become unavailable.
3. Client receives a confirmation email.
4. Calendar entry is created.
5. User sees an error if the slot becomes unavailable before confirmation.

Story splitting and acceptance criteria

Acceptance criteria often reveal when a user story is too large.

If one story has too many rules, workflows, roles, or edge cases, it may need to be split into smaller stories. This makes planning, development, testing, and acceptance easier.

For example, this story may be too broad:

As an admin, I want to manage users, so that I can control platform access.

It could be split into smaller stories:

1. Invite a new user.
2. Assign a user role.
3. Deactivate a user.
4. Reset a user’s access.
5. View user activity logs.

Each smaller story can then have focused acceptance criteria. This helps the team estimate better and deliver in smaller, safer releases.

Common mistakes to avoid

Avoid writing acceptance criteria that are too vague. “The feature should be easy to use” is not testable. A clearer version would define the exact behaviour, message, action, or result expected.

Also avoid turning acceptance criteria into development tasks. “Build the invite form” is a task. “Admin can send an invitation to a valid email address” is acceptance criteria.

The biggest mistake is only covering the happy path. Strong user story acceptance criteria should include errors, permissions, validation rules, empty states, and edge cases where relevant.

Need help turning user stories into build-ready software?

Clear user stories and acceptance criteria help teams reduce rework before development starts. But they work best when they are connected to the right product scope, technical plan, and delivery process.

At Wazobia Technologies, we help startups and professional services firms turn business ideas, workflows, and requirements into custom software that is clear, testable, and ready to build.

If you are planning a SaaS platform, internal system, automation project, or customer-facing product, explore our software development partnership to see how we can support your team from discovery to delivery.

Final thoughts

Acceptance criteria make user stories clearer, testable, and easier to deliver. They help the team understand what success looks like before development starts.

For software teams, this means fewer assumptions, better planning, stronger QA, and smoother stakeholder approval. Start with the user goal, define the expected outcome, include key edge cases, and keep each criterion specific enough to verify.

For a broader overview, read our guide on what acceptance criteria are. For more real-world scenarios, explore these acceptance criteria examples.

FAQs

1. What are acceptance criteria for user stories?

Acceptance criteria for user stories are the conditions a story must meet before it is accepted as complete. They define expected behaviour, rules, edge cases, and outcomes.

2. What is an example of user story acceptance criteria?

For a password reset story, acceptance criteria may include: the user can request a reset link, the link is sent to the registered email, the link expires after 30 minutes, and the user can create a new password.

3. Who writes acceptance criteria for user stories?

They are usually written by the product owner, product manager, or business analyst, then reviewed with developers, QA testers, designers, and stakeholders.

4. How many acceptance criteria should a user story have?

Most user stories need around 3 to 7 acceptance criteria. If the list becomes too long, the story may be too broad and should be split into smaller stories.