How to write strong Acceptance Criteria
Tags: todayilearned, agile
Published: 2020-12-22 09:39:36

## What are Acceptance Criteria (AC)?

> “Acceptance criteria are pre-established standards or requirements a product or project must meet.” -Google

Acceptance Criteria (AC) are unique to each user story and define the feature from the end user's perspective. They form a boundary between what is in scope and what is out of scope.

## Best practices for writing ACs

### Who, When, How?

AC should always be written from the end user's perspective. It is generally written by the product owner/manager or business analyst before actual development starts. This way, the team will be able to capture all the stakeholder needs in advance.

### Shared understanding and consensus

AC synchronise the visions of the client/stakeholder and the product team. They help to ensure a common understanding of the requirements i.e. developers know what behaviour the feature must demonstrate, and the client knows what to expect from the feature. Everyone must review the AC and agree each line.

### Clarity, always

AC must be clear, concise and easy to understand for everyone. They should entail all the functional and non-functional aspects of the feature and be written in simple and plain language. Avoid technical details.

AC should convey the intent and not the solution as the same problem can be solved differently by a different team. Avoid  implementation details.

### Make it testable, measurable and achievable

AC should make it possible to accurately plan and estimate each user story. AC should include clear success and fail scenarios and each criterion should be independently testable so testers can verify that all requirements are met. 

### The structure

The two most common formats are:

### Scenario oriented (Given/When/Then):

  Given some pre-condition, when I perform some action, then I expect some result e.g:

  `User story`: As a user, I want to be able to recover the password to my account, so that I am able to access my account again 

  `Scenario`: Forgot password

  `Given` the user has navigated to the Log in page, 
  `When` the user clicks on the 'Forgot password' button and enters his email address, 
  `Then` he should receive an email from the system to the email address he provided

### Rule oriented:

In other cases, a feature's requirements may not fit nicely into the Given/When/Then format. The rule-oriented form entails that there is a set of rules that describe the behaviour of the feature e.g:

`User story`: As a user, I want to use a search field to enter my postal code, so that I can find the nearest community centre

`Acceptance Criteria`

  - The placeholder disappears once the user starts typing
  - Search starts when the users hits "Enter/Return" on the keyboard or clicks on the "Search" button
  - The search input only accepts numerical digits
  - The search input can't take more than 8 digits
  - etc.

Most requirements can be captured in the formats above, however, it is always possible to write AC in custom formats.

## To recap

Acceptance Criteria (AC) are conditions in which a product must meet in order to be accepted by a user/system. AC define scope, defend against scope creep, clarify requirements and prevents ambiguity. It also helps the QE to verify if development goals were met.

![learned](https://media.giphy.com/media/jdGuxdJabMSTC/giphy-downsized.gif)

What are some other best practices you/your team follow in writing AC? Curious to hear your thoughts/comments below :zap:

## References

[How to Craft Strong Acceptance Criteria for a User Story](https://productcoalition.com/how-to-craft-strong-acceptance-criteria-for-a-user-story-c12792a992b9)

[Acceptance Criteria: Purposes, Formats, and Best Practices](https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices/)