In software development, acceptance criteria are the conditions that software must meet to be accepted by the internal or external customer requesting the software. Specific acceptance criteria can vary widely, but usually refer to a result that happens when the user performs a particular action. Acceptance criteria are often paired with user stories, which explain how the software will be used in real life.
Given this description, some might ask whether acceptance criteria are the same as requirements. They are similar, but they are not the same. While acceptance criteria are the measures by which completed projects are evaluated, requirements are all the software features and functions requested by the client.
In the following sections, we explore more about acceptance criteria including who the acceptance criteria document is written for, what should be on an acceptance criteria checklist, acceptance criteria examples, and how to write effective acceptance criteria.
What Are the Benefits of Using Acceptance Criteria?
The primary benefit of using acceptance criteria is that doing so helps you understand what you’re working toward before you start the project. This benefit may sound simple, but think about the possible outcomes of not understanding what you are working toward. You may waste countless time and money developing something that is not at all what your client wants.
The implications of understanding your clients’ needs include having clearer communication between you and your client as well as between you and your team, minimizing risks and protecting the reputation of your company, ensuring that you know what skills are needed by team members to make the project a success, and limiting the scope of the project. The following video identifies additional benefits of using acceptance criteria.
Who Are Acceptance Criteria Written For?
To ensure the highest quality acceptance criteria, it makes sense to ask, “Who are acceptance criteria written for?” The answer is a variety of stakeholders, which will be different depending on whether the customer is internal or external.
If you are a software engineer working within a company and creating software for that company, the stakeholders include the department requesting the software as well as managers within that department and yours. If you are an engineer working in a firm to provide software to clients, the stakeholders include those clients as well as your own internal managers.
It also makes sense to ask who is responsible for creating the acceptance criteria. The answer here is that it can be anyone who understands the process well enough to write the criteria. Ideally, it is someone not directly involved with the development process, such as a manager. The person or persons best able to clearly define the acceptance criteria are who should create them.
What Items Should Be on an Acceptance Criteria Checklist?
To be sure you are creating high-quality acceptance criteria, consider referencing the following acceptance criteria checklist. Acceptance criteria must:
- Be as simple as possible so every stakeholder can understand them. Remember that a variety of people, including everyone from engineers to managers to investors, may be reading the acceptance criteria document.
- Reflect a pass or fail structure. In other words, stakeholders must be able to answer the question of whether the criteria are met with a “yes” or a “no.”
- Be measurable. These requirements determine when a project is complete, so they must be easily testable.
- Be flexible. That is, they can be accommodated in more than one way.
- Work regardless of the technology or operating system of the user. A software project is not truly complete until it has been tested on all possible systems.
- Focus on end users and what they want to accomplish with the software. Remember that acceptance criteria may be written for people within your organization or your client’s organization but should always be from the standpoint of the end user.
What Is an Acceptance Criteria Example?
As mentioned above, acceptance criteria are used in conjunction with user stories. The user stories are typically identified first, and the acceptance criteria are created from them. User stories are often formatted using the following structure: “As a [specific user], I want to [specific action] so I can [achieve a goal].” For example, “As a budget-minded grocery shopper, I want to search across grocery stores so I can find the best prices on the products I want to buy.”
Acceptance criteria commonly use the following structure: “[Scenario]. Given [the current situation], when [action is taken], then [outcome resulting from action].” One acceptance criterion resulting from the story above might be, “The shopper searches across local grocery stores and finds the best prices on desired products. Given that the shopper has entered 2 or more stores and one product, when the shopper clicks the Find Best Deal button, prices on the product are sorted from lowest to highest.”
How To Write an Effective Acceptance Criteria Document
Finally, here are some tips for writing effective acceptance criteria.
- Start early in the process, specifically before you begin the development process.
- Make acceptance criteria specific enough to be easily evaluated, but broad enough to invite various development approaches.
- Use simple language that does not include jargon. Remember that there are various stakeholders who will be reading the document, including managers and investors who may not understand the lingo.
- Use the INVEST framework, meaning that each story is independent, negotiable, valuable, estimable, small, and testable.
- Ensure that each item in the product backlog or user story has a corresponding set of acceptance criteria.
These tips and the information above should provide a solid starting point from which to initiate, perform, and successfully complete any development project.
