Key Takeaways:
- User stories and acceptance criteria are the backbone of effective Agile project delivery, giving teams a shared language for what needs to be built and how to know when it is done.
- A user story is a short, plain-language description of a feature written from the end user's perspective, following the format: "As a [user], I want [goal], so that [benefit]."
- Acceptance criteria are the specific, testable conditions a user story must meet before it can be considered complete.
- Together, user stories and acceptance criteria sit at the heart of the Agile process, guiding sprint planning, development, and quality assurance from start to finish.
- Writing user stories and acceptance criteria is a collaborative responsibility: product owners, developers, designers, and testers all bring essential perspectives to the process.
- A complete user story often includes more than just the core statement and acceptance criteria; requirements, assumptions, and dependencies all play an important role.
- User stories and acceptance criteria can be updated during a project, but changes mid-sprint should be handled carefully and transparently to avoid disruption.
What is a User Story?
Definition
A user story is a short, plain-language description of a feature or functionality written from the perspective of the end user. The purpose is straightforward: to keep the focus on the person using the product, not on technical implementation details.
User stories follow a simple, structured format:
As a [type of user], I want [a goal or action], so that [the benefit or reason].
This format, often called the "who, what, why" structure, forces the team to think about who they are building for, what that person needs to do, and why it matters to them.
User stories sit within a broader product backlog and are typically estimated, prioritised, and completed in sprints. They are small enough to be delivered within a single sprint, which is usually two weeks.
User Story Example
Here is a practical user story example for a website with a contact form:
As a prospective client visiting the Somar Digital website, I want to submit an enquiry through a contact form, so that I can get in touch with the team without needing to find and open my email client.
This tells the development team who the user is, what action they want to take, and what outcome they are trying to achieve. It says nothing about how the form should be built (that comes later) through acceptance criteria and technical discussion.
User stories work best when they describe a single, focused need. If a story starts to feel too large or covers multiple distinct goals, it is worth splitting it into smaller stories.
Want to Learn More About User Stories?
If you would like a deeper dive into what user stories are and how to write them well, read our full guide: What is a User Story?
What is Acceptance Criteria?
Definition
Acceptance criteria are the specific, testable conditions that a user story must meet before it can be considered complete. If a user story answers the question "what does the user need?", acceptance criteria answer the question "how do we know we have built it correctly?"
They are typically written as a list of conditions that the delivered feature must satisfy. They are agreed upon before development begins, so there is no ambiguity about what done actually means.
The "Given / When / Then" format looks like this:
- Given [a context or precondition]
- When [an action is taken]
- Then [an expected outcome occurs]
This format is particularly useful because it maps directly to how the feature will be tested, making it easier for QA (Quality Assurance) testers and developers to validate work.
Acceptance Criteria Example
Using the contact form user story from above, here is what the acceptance criteria might look like:
User Story: As a prospective client, I want to submit an enquiry through a contact form, so that I can get in touch with the team without needing to open my email client.
Acceptance Criteria:
- Given I am on the contact page, when I view the form, then I can see fields for my name, email address, phone number (optional), and message.
- Given I complete all required fields and click "Submit", then I receive an on-screen confirmation message that my enquiry has been received.
- Given I submit the form successfully, then the Somar Digital team receives my enquiry via email within two minutes.
- Given I attempt to submit the form with an empty required field, then I see an inline validation error that tells me which field is missing.
- Given I enter an incorrectly formatted email address, then I see a validation error before the form submits.
- Given I am using a screen reader, then all form fields have descriptive labels that read aloud correctly.
Each criterion is specific, binary (it either passes or fails), and testable.
Why is Acceptance Criteria Important?
Acceptance criteria serve several critical functions on a project:
- Defines "done" clearly: Without acceptance criteria, "done" is subjective. One developer might think a feature is complete when it works on their machine; a product owner might expect it to handle ten edge cases. Acceptance criteria make both parties accountable to the same standard.
- Prevents scope creep: When criteria are agreed upon before development starts, it becomes much easier to identify when something is being added beyond the original scope. This protects both the team and the timeline.
- Improves communication: Acceptance criteria give product owners, developers, designers, and testers a shared reference point. Everyone can look at the same list and agree on whether a feature is ready.
- Supports quality assurance: Testers can use acceptance criteria directly as a test plan. Rather than guessing what to check, they work through each criterion systematically.
- Reduces rework: When expectations are documented upfront, teams spend far less time rebuilding features that were misunderstood. This saves time, reduces frustration, and keeps projects on budget.
- Keeps user needs central: Because acceptance criteria flow directly from user stories, they keep the team anchored to what users actually need, rather than drifting towards technical solutions in search of a problem.
Further Reading
For a detailed look at how acceptance criteria relate to the definition of done read our blog: Definition of Done vs Acceptance Criteria
How Do User Stories and Acceptance Criteria Fit into the Agile Process?
In most Agile frameworks, user stories live in the product backlog – a prioritised list of all the work that needs to be done. Before each sprint, the team pulls stories from the top of the backlog during a sprint planning session. At this point, acceptance criteria should already be written and reviewed. If they are not, the story is not ready to be worked on.
During the sprint, developers build to the acceptance criteria. At the end of the sprint, the product owner and testers verify that each criterion has been met before marking the story as complete. This cycle (plan, build, verify) is what makes Agile both flexible and rigorous.
Who Writes User Stories and Acceptance Criteria?
Coming up with user stories and acceptance criteria are a collaborative endeavour, usually between the project team and the client.
Typically, the product owner or scrum master drafts the initial user story, drawing on research, stakeholder input, and their understanding of user needs. However, the acceptance criteria are best written collaboratively, involving:
- The product owner, who knows what the business needs
- The scrum master, who makes sure everything is kept in check
- Developers, who understand what is technically feasible and can flag ambiguities
- UX designers, who bring insight into user behaviour and edge cases
- QA testers, who know what needs to be testable and how
The goal is to surface assumptions, resolve ambiguities, and agree on the acceptance criteria before a single line of code is written.
Is There Anything Else Included in a User Story? Requirements and Assumptions
Yes – depending on the team's practices, a user story might also include:
Requirements are the additional technical or business rules that constrain how a feature should be built. For example, a requirement on the contact form story might be that all form submissions must be stored in the CMS (Content Management System) as well as sent by email, for audit purposes. Requirements inform the technical approach without prescribing it.
Assumptions are the things the team is taking for granted in order to move forward. Documenting assumptions is valuable because it makes hidden dependencies visible. For example, an assumption might be: "We are assuming the client's email server can receive automated messages without them going to spam." If that assumption turns out to be wrong, the team knows immediately what needs to change.
Together, user stories, acceptance criteria, requirements, and assumptions give the development team everything they need to build with confidence.
Can You Change or Update a User Story or Acceptance Criteria During a Project?
Yes – user stories and acceptance criteria are not carved in stone. However you need to proceed with caution if you start changing user stories during a sprint. The general guidance is:
Before a sprint: Stories and acceptance criteria can be freely updated as new information comes to light. This is expected and healthy. Backlogs should be regularly refined — a process called backlog grooming or backlog refinement.
During a sprint: Changes should be approached with caution. If a significant change is needed mid-sprint, the product owner and team need to assess the impact together. Sometimes it is better to complete the story as originally scoped and create a new story to capture the change.
The key principle is transparency. If something changes, everyone needs to know. Acceptance criteria that are quietly updated without team awareness create confusion and erode trust.
Bringing It Together
At Somar Digital, we work collaboratively with our clients to develop user stories and acceptance criteria that reflect real user needs and set projects up for success. Our Agile approach means we are transparent at every step, and our clients are always informed participants.
If you are working on a digital project and want to make sure it is built on solid foundations, get in touch with the Somar Digital team. We would love to talk through how we can help.
