Guiding Principles for Acceptance Criteria

Once you’ve mastered the art of writing beautifully structured user stories, it’s time to move on to honing the craft of writing great acceptance criteria. There are different types of user stories. Some are at the page level, some are at the field level, some are about saving and validation, some are about error messages. Depending on the nature of the user story, the acceptance criteria will follow suit. Establishing a clean, consistent format from the get-go makes it much easier on the writing, reviewing, and consuming of acceptance criteria. Let’s dive into the guiding principles for acceptance criteria collected over the last two decades of software development.

1. The type of user story will dictate the type of acceptance criteria.

Depending on the nature of the user story, the acceptance criteria will follow suit. This makes it easy to use a consistent format for acceptance criteria across thousands of user stories. Here are some examples of acceptance criteria types:

AC Type: Page
AC Type: Messaging
AC Type: Binary Selection
AC Type: Date Selection
AC Type: Text Entry
AC Type: Saving
AC Type: Errors

2. Stay agnostic of design and dev. Do not dictate how something will be done.

Acceptance criteria should never dictate or attempt to describe how design or dev should be carried out for an application. In order to stay agnostic of what the designers and developers are going to come up with, always stay focused on the “what” and not the “how”.

3. List acceptance criteria in a logical order.

The order in which you list out acceptance criteria will make it easier for designers, developers, and testers to do their part. I typically start from the top of a logic tree and work my way down. Typically, you’ll start with application criteria and work your way down to user criteria.

4. Begin each sentence with “application” or “user”.

Begin each sentence of acceptance criteria with either “application” or “user”. Here are a few examples:
- Application loads correct fields on page, based on employer rules.
- Application loads correct validation rules, based on state rules.
- User can tab through each field in the correct order, starting from top left.

5. Use simple phrasing, consistency, and parallel sentence structure.

By the end of a program, you might have over 10,000 lines of acceptance criteria. For this reason, it’s incredibly important to use simple, consistent phrasing and parallel sentence structure throughout. Acceptance criteria is easier to read and comprehend when it is written with care.

6. Use a clean, flat structure. Avoid nesting.

Similar to other content, acceptance criteria is easier to read when you use a flattened list. Do not nest bullets. Do not nest numbers. The ragged edge makes it more difficult to read.

7. Don’t include copywriting.

Don’t include copywriting in the acceptance criteria, otherwise you’ll run into sync issues. Each design mockup should always contain the actual proposed copywriting, baked right into the mockup itself. In this way, all copywriting lives in situ and can be reviewed in context of the screen. This is important for ease of review, ease of coding, and ease of testing.

8. Don’t include user roles.

Don’t include user roles in the acceptance criteria, otherwise you’ll run into sync issues. Because user roles have already been defined at the user story level in a separate field, there’s no need to list out user roles in acceptance criteria. If something changes at the story level, you might forget to make the update at the criteria level, thereby creating a sync issue. List out user roles explicitly only if there is criteria that is role-specific.