Acceptance Criteria for User Stories and their role in product development

This article provides a comprehensive overview of the key aspects of acceptance criteria and their important role in various product development projects.
We define Acceptance Criteria, how to properly create them based on user stories and how they contribute to business goals, review the different formats of acceptance criteria and learn how each can be applied to define product requirements and standards.

When we embark on the development of a new product or functionality, we face an exciting yet sometimes challenging journey, where inspiration and ideas alternate with uncertainty. At the very beginning of this journey, we lack a complete picture, and we ask ourselves: How do we create a user experience that fully meets the expectations and needs of future users? How do we ensure that each product feature serves its purpose rather than just filling space?

It’s like venturing into an unexplored forest where we’ve never been before, unsure of where our journey will end, finding ourselves in unfamiliar territory with new possibilities, discoveries, and, of course, risks. No matter how experienced we are in our field, each new project presents a unique challenge that requires creativity and resourcefulness. Often, these feelings of uncertainty arise during the requirements gathering and user research phase of the design process. It is precisely in these moments that Acceptance Criteria work their magic. They become a bright compass, helping us pave the way and determine the right direction.

“True mastery is revealed in the ability to make the complex simple and consistently move towards the set goal.” — Albert Einstein.

When we are provided with a clear vision of what the product should achieve, every step on this path becomes more confident and justified. In the field of UX design, Acceptance Criteria play a crucial role in ensuring a smooth and successful product development process. These criteria enable the project team or client to ensure the successful completion of tasks or projects, they serve as an essential tool to guarantee a successful development process and ensure that the end product fully satisfies the client’s and users’ requirements and expectations.

Research shows that different stakeholders may have different visions of the end result of product development, which often leads to unintended consequences and inefficient use of resources. According to ZipPo’s “Exposing The Truth: Software Project Failure Statistics In 2023” analysis:

25% of technology projects meet a premature demise, crumbling outright without a chance for recovery. As if that’s not disconcerting enough, approximately 20–25% struggle to muster a positive return on investment (ROI), ultimately failing to justify their financial outlay. To add insult to injury, an astonishing 50% face a harsh reality, requiring extensive revamping upon completion to merely function as intended.

In the realm of Software Project Failure Statistics, one cannot overlook the staggering fact that 39.03% of project failures stem from poor requirements. This compelling figure accentuates the significance of accurately defining, understanding, and communicating project requirements throughout the product development lifecycle. In the intricate dance between project success and failure, this statistic shines a spotlight on the vital role that well-articulated requirements play in determining project outcomes.

What are acceptance criteria and their role in the project?

Acceptance Criteria (AC) are the conditions that a product must meet to be accepted by the user, customer, or, in the case of system-level functionality, the consuming system. In simpler terms, they constitute a list of details (also known as requirements) outlining how a new feature should function and appear. Acceptance criteria define the specifics of user stories, so separate criteria should be written for each story. It is important to note that they should only describe what needs to be accomplished, the product features, and the functions it performs, without delving into solution details and methodologies.

During this stage, understanding the customer’s desired goal is crucial. If a user story is created as a formulation of intent to give the team freedom in finding a solution, then acceptance criteria serve as precise details unique to each user story, comprising a set of conditions that confirm its implementation.

I would like to add a definition of Acceptance Criteria, which in my opinion most accurately describes their significance and importance in the development process.

Acceptance criteria (AC) are a set of predetermined requirements that must be complied with to ensure that all scenarios are considered and user stories are accomplished subsequently. Since different team members are involved in the process of product development, it is important to eliminate the gaps that are standing in the way between the client vision and the development delivery. With acceptance criteria, each particular feature in the user story is defined to ensure that deliverables meet the client’s requirements.
[Brief Guide on How to Effectively Craft Acceptance Criteria for User Stories]

‍

What are user stories?

User stories are brief descriptions of functionality or requirements for a product, formulated from the perspective of the user. They represent the requirements of product owners, expressed in a language understandable to them. User stories help the development team better understand the users’ needs and focus on creating valuable features.

In the book “User Story Mapping: Discover the Whole Story, Build the Right Product” by Jeff Patton, a user story is defined as a concise, simple description of a feature or functionality from the perspective of the end-user. It represents a single piece of valuable functionality that can be delivered in an iterative manner. User stories are used as a means of communication between the development team and stakeholders, providing a clear understanding of what needs to be built and why it is important for the users. These stories help in breaking down complex projects into manageable parts, allowing the team to prioritize and deliver incremental value to the users.

How to create a user story?

The following formula is used to create a user story:

As you can see, the format of a user story is very simple and leaves no room for elaboration. However, that’s precisely why it is used. User stories typically consist of 10–15 words, allowing a clear description of the essence of your product and what you are trying to achieve with it. The first part describes who will be the user of your product. The second part should clarify the function you are creating. In the final part, you need to describe why you are creating this feature and also why you believe the customer would want to use it.

Above is a very basic user story template. How can something so simple be so difficult to get “right”? Unfortunately, getting user stories “right” can be challenging at first. It is essential to learn how to create user stories that meet the product’s needs. This skill can be developed over time, but I’m going to save you the effort of learning.

As Bob Hartman writes in the article “New to agile? INVEST in good user stories”, to create good user stories, start by remembering to INVEST in them. Based on the INVEST model (created by Bill Wake), you can significantly improve the process of creating user stories and requirements for your project. Here are some tips on how to apply the INVEST model:

1. Independent: Ensure that each user story is separate and self-contained, allowing it to be worked on independently of other stories.
2. Negotiable: Avoid excessive details in user stories, leaving room for the development team and stakeholders to negotiate the specifics.
3. Valuable: Pay special attention to ensuring that each user story delivers value to users or customers by addressing their real needs.
4. Estimable: Phrase user stories in a way that the team can estimate their complexity and workload to plan resources and timelines.
5. Small: Strive to make user stories as small and specific as possible, making them easily incorporable into development iterations.
6. Testable: Ensure that each user story is testable, allowing for verification that it has been successfully implemented and meets requirements.

How user stories relate to Acceptance criteria?

User stories are smaller in size and represent individual, distinct pieces of functionality within an epic. They are bite-sized units of work that the team can commit to delivering within a single iteration. Acceptance criteria specify the expected outcomes of the user story. Epics, on the other hand, are tasks containing high-level functional and non-functional requirements for a large feature or a group of related features. Usually, an epic covers an entire usage scenario for your customers and includes all the basic characteristics and functionalities necessary to address that scenario.

What are Acceptance Criteria used for?

Acceptance Criteria (AC) are essential for any project to ensure that a feature meets all necessary requirements. They provide a clear, concise, and measurable definition of what needs to be done for the product feature to be marked as successful. Acceptance criteria should be agreed upon before starting work on the feature. They can be used to evaluate whether the result is complete and fit for its purpose or serve as a tool forzz communication between different stakeholders involved in the project.

Here are the key purposes and benefits of using Acceptance Criteria:

1. Enhance Information: They expand on the initial information, supplementing the user story and providing a more detailed description of what needs to be achieved and how to assess the task or project’s success.
2. Setting clear standards: They establish clear and specific quality and completion standards for the product, ensuring its functionality aligns with user expectations and project goals.
3. Improve Communication: They enhance communication between the team and stakeholders, synchronizing their vision, helping to align expectations, and ensuring mutual understanding.
4. Accelerate Development: When the team understands clear success criteria, they can efficiently and purposefully execute tasks, minimizing delays in the development process.
5. Identify Negative Scenarios: Acceptance criteria identify and describe negative scenarios, helping to uncover and prevent potential issues or errors.
6. Planning and Estimation: They allow for better planning and estimation of upcoming tasks in terms of time and required resources for task completion.
7. Enhance Product Quality: By preventing potential mistakes and omissions through early identification and resolution of potential issues, acceptance criteria contribute to higher product quality.
8. Ensure Requirements Compliance: They ensure the product or feature aligns with user expectations and needs, verifying requirements adherence.
9. Establish Project Boundaries: They help set clear project boundaries, enabling effective change management and reducing the likelihood of scope creep, which can mitigate risks and facilitate planning.

Acceptance Criteria types and structures

There are several types of acceptance criteria. Both approaches have their merits and are key to ensuring that features are genuinely useful for users. The choice between them often depends on the context and preferences of the team and stakeholders. In some projects, a combination of both types of acceptance criteria may prove beneficial to ensure comprehensive coverage and clarity throughout the product development process.

1. Scenario-oriented Acceptance Criteria (Given-When-Then) illustrate the sequence of executing each criterion: “Scenario: (description of the scenario). Given (precondition), When (action is performed), Then (result is achieved).” These criteria are oriented towards the user’s perspective and describe the expected interaction with the product under various conditions. Unlike rules-oriented criteria, scenario-oriented criteria provide a more visual and contextual representation of the expected behavior. Given-When-Then is an approach developed by Daniel Terhorst-North, in 2003, to represent test/behaviour scenarios as part of Behavior-Driven Development (BDD). If you’re curious about BDD user stories, read Daniel’s article about it here.

2. Rules-oriented Acceptance Criteria (checklist) focus on defining specific rules and conditions that the product or feature must meet to be considered acceptable. These criteria often take the form of “if-then” statements or business rules. They describe the expected behavior of the system in response to certain input data or actions. The primary emphasis is on defining clear, objective, and measurable acceptance conditions. In Rules-oriented AC, as the name suggests, you start with a set of rules. Together with the team, you create a list of statements reflecting scenarios for passing or failing. These statements define the conditions that must be met for the user story to be completed. The rules-based format is quite straightforward, with passing or failing assertions typically presented as a bulleted list. The scenarios are constructed based on a specific set of rules.

‍

How to Write Acceptance Criteria Properly?

Writing acceptance criteria may seem relatively simple and not require much time. However, this notion is mistaken. Before starting to create your own criteria, it is essential to be familiar with specific strict requirements that all acceptance criteria documents must adhere to. These requirements are applicable to any type of criteria and play a vital role in ensuring their effectiveness and reliability. Writing acceptance criteria for the first time may appear to be a challenging task, but once you become familiar with the process, you will use them in all your projects.

Tip #1: Write the Acceptance Criteria from the user’s perspective
By framing acceptance criteria from the user’s perspective, it ensures that the requirements are clear and understandable to all stakeholders, including developers, testers, product owners, and end-users. Using user-centric language avoids technical jargon and helps bridge the gap between technical teams and business stakeholders.

Tip #2: Acceptance Criteria should be clear, concise and unambiguous
The main challenge of writing good acceptance criteria is to keep a balance between detail and broadness. As they say, it’s hard to make something simple, so you need to keep your AC documentation concise and clear, but not restrictive. Avoid vague language and make sure each criterion leaves no room for interpretation. Use concrete terms that everyone involved in the project can understand.

Tip #3: Use simple language
Your acceptance criteria should be easily understandable by all members of your team, regardless of their technical knowledge. All stakeholders, from end-user to developers, must have a common understanding.

Tip #4: It should be achievable and testable
Communication with stakeholders ensures the progress is going in the right direction. Further, to make it achievable, you consider it as a reasonable minimum amount of functionality that you can provide. Make sure that the feature could be tested. That is why acceptance criteria should be clear and concrete.

Tip #5: Collaborate with your team
Writing acceptance criteria should not be done in isolation. Involve your team in this process as they can provide valuable insights and help ensure that everyone is on the same page about what needs to be achieved

Tip #6: Don’t write too much Acceptance Criteria for one user story
The optimal number of criteria for one uncompleted task is no more than three. If there are significantly more (from six), it makes sense to divide the user story into several. This practice allows for faster delivery, and faster feedback and minimizes the risk of failure.

Tip #7: Relate to User Story
Ensure that each acceptance criterion directly corresponds to the user story it relates to. It should outline the conditions that must be met to consider the user story complete.

Tip #8: Prioritize and organize
Rank the acceptance criteria in order of importance. This helps in case some criteria cannot be met due to time constraints or other factors; the most critical aspects are addressed first.

Tip #9: Review and revise
Regularly review and revise acceptance criteria as the project progresses and new information becomes available. This helps in adapting to changing requirements and maintaining relevance.

Tip #10: Use Acceptance Criteria templates
Consider using standard templates for writing acceptance criteria. These templates can ensure consistency across all user stories.

Quick Summary of Acceptance Criteria

One of the issues that hinder teams from achieving business goals and growing products is inconsistency. Without Acceptance Criteria (AC), there is a risk that a user story will be poorly understood or implemented, leading to disappointment for both parties. However, with AC in place, both the customer and the team can be confident that the product will meet their needs. As a given problem may be perceived differently by each team, ensure that everyone (programmer, tester, analyst, UX-designer, or project manager) agrees with the product’s assumptions before starting development work. The more information you give to the development team, the better and cheaper the project will be.

‍

I hope you find this article helpful

‍