The Importance of Having Project Acceptance Criteria in Your Projects

Last updated on 15th Jul 2020, Blog, General

Acceptance criteria are a range of conditions that a given product must satisfy before the end-user, consumer, or group of stakeholders accepts it. These set of statements specify whether a project passes or fails the functionalities and requirements set forth by users. In simple terms, they represent if a customer is satisfied with certain criteria or not.

These criteria reinforce the work that a team is doing by defining measurable margins of user stories. It helps both parties determine when a project is completed and working properly.

In order for acceptance criteria to work, they must be easy to understand for both teams and users. They need to be clear and concise, and easily rendered within different tests. It is important to note that acceptance criteria shouldn’t be a copy of requirement documents. They are two separate things. The criteria should aim to define the limits of a user story while helping the entire team understand the needs of the stakeholders or product owners.

Acceptance criteria types and structures

AC can be written in different formats. There are two most common ones, and the third option is to devise your own format:

• scenario-oriented (Given/When/Then)
• rule-oriented (checklist)
• custom formats

As the first and the second formats have very specific structures, we’ll mostly focus on them. However, you may find that other formats fit your product better so we’ll briefly touch on them as well.

When Should they be Written?

It is common practice to write the acceptance criteria while the user story is being discussed, as this usually helps a team with estimation. However, they can also be jotted down when the story gets picked.

Acceptance criteria will often give life to a lot of conversations from developers, especially when the story hits their meeting room. Generally, the problems and thoughts brought up during these conversations are added to the acceptance criteria.

There is no specific time when these criteria must be written, just as long as they are established before developers begin to work on the project.

When developers are done working on a user story, they must show the final product to the product owner, and prove how each criterion is met. This forces a team to focus on how features work from the customer’s perspective, and it also limits the developers from adding a number of unnecessary functionalities to a project.

The 3 Aspects of Good Acceptance Criteria

Functional and Non-Functional Requirement

There are different types of requirements that identify specific user tasks, functions and requests. These can be broken down in functional and non-functional

requirements. A functional requirement refers to a technical aspect of a project. For example, “If a user clicks on ‘Send Message’ Outlook will pop up.” A non-functional requirement deals with non-practical aspects such as the colour of buttons and windows inside an app.

Good acceptance criteria separate these two functionalities, and then properly categorize them.

Expected Performance

Expected performance is normally measured as a response time. For example, 1-3 seconds to query a response. This should always be stated as a goal, and not a solved solution. For example, “A user can generate an audit form” as opposed to, “A user can click submit to generate an audit form.” The criteria should not state how the solution would be implemented, as it limits the options and creativity of developers.

Outstanding Defects:

A good Acceptance Criteria clearly defines the acceptable parameters of outstanding open defects. They answer all questions in regards to how and when they should be addressed, as well as how they should be prioritized.

Example of Acceptance Criteria

Let’s say that the customer of an online shopping catalogue wants to implement advanced search options on the front page, so that his users can quickly and easily refine their search.

The acceptance criteria should be written in a simple to understand language that the customer can decipher, similar to the user story. It can include something like:

• Limit the search by format and type.
• Delineate the search by a date range.
• Limit the search to publisher info like author, title, subject, publisher, and place.
• Restrict the search to specific collections and brands.
• Filter search by availability

User story:

• As a Harvard University student
• I can see my fee for the semester 
• so that I know the remaining balance

Acceptance criteria examples:

• The semester fee balance is displayed
• The semester fee balance is calculated
• The fee balance is displayed for that semester duration
• The balance is not displayed if an unknown student identity is applied