Acceptance criteria

In product development, successfully delivered value depends on stakeholders being in agreement.

Acceptance criteria help define expectations and promote transparent communication. They identify the specific needs that a feature must fulfill to be considered fully realized.

Without them, development teams risk starting inefficient sprints, resulting in rework and frustrated stakeholders.

Acceptance criteria and user stories are related but quite different ideas that this article clarifies. Additionally, it examines the qualities of well-written acceptance criteria, how they aid in the development process, and offers helpful advice on creating effective acceptance criteria.

What are acceptance criteria?

Acceptance criteria are a list of conditions an increment of work must meet to be considered complete. They're a collection of clear, short, and testable statements aimed at producing valuable customer outcomes.

Acceptance criteria concern the task's result more than how you arrive at a solution.

What's the difference between user stories and acceptance criteria?

A user story is a means to express a product backlog item (PBI) or, in even broader terms, Value Items, as they are called in Agile Tools. Your team may define and describe Value Items using a method different from user stories, such as "ordinary" tasks.

A user story (a type of Value Item) and acceptance criteria reinforce each other.

Although the acceptance criteria are not fundamental in the Scrum framework, many Scrum and agile teams use them to organize work and achieve positive outcomes. The roots of acceptance criteria are in XP (eXtreme Programming).

Here is an example user story:

As a User, I can add Acceptance Criteria to a Value Item, so that the team can verify if Value Item can be accepted.

And a list of conditions (Acceptance Criteria) as agreed with the team:

• Acceptance Criteria (AC) is a section on the Value Item (VI) detail page.
• The AC is displayed on VI types: Task, Epic, and User Story.
• Each AC entry has a status and a title.
• I can add an AC entry by clicking on a + icon.
• I can delete the AC entry.

And there could be (many) others.

User stories perfectly capture the motivation behind a backlog item for a product, which is crucial for managing the backlog. They communicate the rationale behind the development effort, describe the intended functionality or feature, and summarise the client's needs.

Acceptance criteria set requirements that must be met for an item to be considered complete. By measuring the development process's effectiveness, these standards ensure that the functionality delivered satisfies user needs.

Let's see another example. The user story:

Qualities of effective acceptance criteria

Effective acceptance criteria have several essential qualities that promote transparent communication and a smooth development process.

In a way, you can think of acceptance criteria as sub-tasks, but they must be user-oriented, clear, concise, and verifiable.

User-oriented

• Focus on user needs: Acceptance criteria should be framed from the end-user's perspective.
• Avoid technical jargon: Use plain language that is easy to understand for technical and non-technical stakeholders.
• Prioritize user experience: Consider how the feature will impact the user's experience and satisfaction.

Clear

• Unambiguous language: Use clear and concise language to avoid misunderstandings.
• Specific requirements: Clearly define what is expected from the feature or functionality.
• Avoid vague terms: Replace vague terms like "fast" or "efficient" with specific metrics or standards.

Concise

• Keep it brief: Avoid unnecessary details and focus on the essential requirements.
• Single focus: Each acceptance criterion should address a single, specific aspect of the feature.
• Prioritize clarity over brevity: While conciseness is important, clarity should always take precedence.

Verifiable

• Testable conditions: Acceptance criteria should be written in a way that allows for easy testing and verification.
• Measurable outcomes: Define specific, measurable outcomes that can be used to assess whether the criterion has been met.
• Objective criteria: Use objective criteria that can be verified by multiple individuals.

Adhering to these principles can help you create acceptance criteria that drive effective collaboration, ensure quality, and ultimately deliver products that meet user needs.

Who should write acceptance criteria?

Because we all operate in different businesses, acceptance criteria may not always come from traditional customers. Instead, it may be your product owner's or other stakeholders' criteria.

Some of the options for defining acceptance criteria are:

• Conversations with clients or customers
• Discussions with stakeholders
• During product backlog refinement
• During scrum sprint planning and team brainstorming

Product owner: The product owner, who has a solid understanding of customer needs and product vision, is critical in starting the conversation and defining the desired functionality.

The development team's technical experience provides vital insights into the criteria' feasibility and testability. They can recommend acceptable methods for structuring the criteria so that they can be clearly evaluated.

Scrum master: The Scrum master facilitates team discussions and ensures everyone has a voice. They can also help ensure that the criteria follow best practices.

While the product owner may lead the process, the final criteria should be a collaborative effort that considers all stakeholder perspectives. This collaborative approach promotes common understanding and raises the likelihood of creating the desired outcome.

When should we write acceptance criteria?

While we initially identify acceptance criteria during backlog refinement, the finalization should occur just before development starts to ensure alignment with the latest requirements.

The scrum team ensures they work with the most up-to-date information by finalizing acceptance criteria during sprint planning. This collaborative process involves reviewing criteria, addressing questions or concerns, and determining if the work suits the upcoming sprint.

Scrum prioritizes customer satisfaction and delivers value early and often. Acceptance criteria are refined and finalized close to development to ensure alignment with the customer's evolving needs. Traditional project planning may focus more on completing the project within a specific timeframe and budget, potentially leading to less flexibility in responding to customer feedback.

How to write acceptance criteria?

Templates are available online, but Scrum, as a light framework, does not mention the acceptance criteria. It talks about the Definition of Done.

Checklist

Many teams use a bullet list. The list is simple to create and may be included in the user story or any other location where you plan your sprint's work.

Scenario-based template

Given (context or precondition), when (I take this action), then (this will be the result).

Examples of Acceptance Criteria

As a customer, I can add items to my cart so that I can purchase them later.

• The system shall display the "Add to Cart" button on each product page.
• Clicking the "Add to Cart" button shall increment the quantity of that product in the cart.
• The cart shall display the total number of items and the total price.
• The system shall allow users to remove items from the cart.

As an admin, I can view user activity logs so that I can monitor user behavior and identify potential issues.

• The system shall display a user activity log page.
• The log shall include information such as: User ID, Timestamp, Action performed (e.g., login, logout, purchase, search), IP address.
• The system shall allow admins to filter the log by date range, user, and action type.

As a registered user, I can reset my password so that I can access my account.

• The system shall display a "Forgot Password" link on the login page.
• Clicking the link shall redirect the user to a password reset form.
• The password reset form shall require the user to enter their registered email address.
• The system shall send a password reset link to the user's email address.
• The password reset link shall expire after a certain time period.
• The system shall allow the user to create a new password using the reset link.

Avoid common mistakes while writing acceptance criteria

Although there are numerous approaches to tailor acceptance criteria to your organization, there are also typical mistakes that tend to contradict AC's goals:

• Disregarding the perspective of the user.
• Instructing the developers on "how" to do the task.
• Creating acceptance criteria too soon.
• Writing the acceptance criteria after the sprint's work has started.
• The criteria are general.
• The criteria are not clear.
• There are too many requirements; if so, you might need to divide the work into smaller portions.

Use acceptance criteria with Agile Tools

In contrast with many leading project management tools on the market, Agile Tools treats acceptance criteria as a first-class feature.

You do not have to fiddle with custom fields or (buying) plugins; it is there for you to use.

Each criterion is not a simple checklist item, but it also allows you to set a status on every criterion. Currently, it is one of Draft, To-do, In progress, Available, Done, Blocked, and Pass.

Acceptance criteria versus Definition of Done

As you might have noticed from the above animated gif, there is also a Definition of Done section.

If the Acceptance Criteria are for the Value Items, the Definition of Done is "up one level" for the Value Units (products, services, projects, …).

Since the Scrum guide does not mention acceptance criteria but does Definition of Done, there needs to be more clarity when using both terms.

The difference is that the same Definition of Done applies to every Value Item for a given Value Unit.

The Acceptance Criteria are different for each Value Item.

But let's discuss this in another post.