User stories and acceptance criteria

A user story is a conversation about value and behavior, not a way to fit requirements into a single sentence. Acceptance criteria should remove ambiguity on important branches of the scenario, including errors and access rights, but not turn into a step-by-step technical solution.

What are user stories and acceptance criteria

Definitions and objectives

A user story is a short description of a user’s or case needs. The structure is usually this: As a user, I want to [act] to [purpose]. Acceptance criteria are clear conditions for a story to be fulfilled. They specify requirements and serve as a checklist for verification.

User stories answer the question of who wants what, acceptance criteria – when this request is implemented correctly.

Examples of work

Example user story: As a registered user, I want to change my password to improve the security of my account.

Acceptance criteria:

1. The user can change the password on the profile page.
2. New and old passwords must be filled in.
3. Error when the old password is inconsistent.
4. After changing the password, the user receives an email notification.

Why User Stories Are Needed in Delivery

Relationship to supply processes

User stories are the main element for planning and partitioning work on tasks. If the story is specific and short, the team will evaluate the workload, not miss details, and not get confused by the requirements.

Acceptance criteria turn wishes into measurable results. These are the acceptance criteria – they check that they have delivered exactly what they need, and they have not missed anything.

How it helps.

In planning:

• Stories are convenient to discuss with the team - everyone knows what success looks like.
• Faster identification of complex or unclear moments at the stage of extremely cheap - before implementation

In testing:

• Acceptance criteria - the basis for the test cases
• Automating BDD screening is easier when the criteria are clearly defined.

Reception:

• The product manager does not need to think: checklist is ready
• There is no difference between business and team

Example: If you describe the story for the feedback button only as “Make a feedback button”, the design and behavior may differ from expectations. If you add clear acceptance criteria – view, place, reaction to click, then unexpected questions will not arise.

How to write good user stories and acceptance criteria

Best practices for design

User Stories: Short, structured, without unnecessary details. Don’t go into technical tasks like “Make REST API.” Think from a user perspective.

Acceptance criteria: unambiguous, verifiable, without overlapping with each other.

Recommendations:

• One story, one user task
• Acceptance criteria cover all behaviors, including negative scenarios.
• Without value judgments like “quickly” or “beautiful”

Anti-patterns and errors

Frequent errors:

• Stories without an explicit user or purpose
• Acceptance criteria do not cover extreme cases
• Criteria contradict each other or are duplicated.
• Acceptance criteria only happy path – no errors

Example: On the project planned feature “Share an article”. Acceptance criteria did not take into account that a link could be private. As a result, users shared private materials publicly. If the criteria were given more attention, the incident would have been avoided.

Validation and acceptance: processes, roles, metrics

Who is responsible and what to check

Most often, the product manager or product owner is responsible for formulating user stories and acceptance criteria. Developers, testers, designers are involved in the discussion to check the feasibility and completeness.

At the delivery stage, they are carried out:

• Grooming (requirements analysis and clarification of criteria)
• Demonstration (demo) of the completed task on acceptance criteria
• Acceptance of feature on the checklist of criteria

Metrics and quality

The exact time for accepting and correcting bugs depends on the market and the company. In practice, we see:

• Percentage of user stories with formalized acceptance criteria
• Time from completion to acceptance (cycle time)
• The number of defects not caught at the stage of description

How to use user stories and acceptance criteria in tools

In jira, backlog, bdd

In jira user stories and acceptance criteria, tasks are usually described. Acceptance criteria can be kept as a separate checklist, which is convenient for testing and automation. If your team uses BDD (Behavior Driven Development), the criteria are described in the Given–When–Then format.

Example for BDD: Given user on the profile page When you enter the correct old and new password Then there is a message about a successful change, an email is sent.

How not to lose criteria when changing

In practice, it is often forgotten to update acceptance criteria when requirements change. Solution: keep the criteria in a single source of truth (e.g. jira or general doc) and keep track of their relevance every time you edit a story.

FAQ: Frequent questions

**How does a user story differ from a task? A user story describes a user’s need, a task is the specific work that needs to be done to implement the story.

Who is the acceptance criteria? The product manager usually responds. But the criteria should be clarified together with developers and testers.

**Can I change the acceptance criteria during the sprint? It is better to avoid it, otherwise planning loses its meaning. If the criteria change, talk to the team.

**What to do if acceptance criteria are missed? Go back to the story, add criteria before development starts. Otherwise, misunderstandings are ensured.

Are negative scenarios required in acceptance criteria? Preferably, otherwise mistakes and deadlocks will pass by.

Where can I read more? Atlassian guide
Mike Cohn: User Stories