Acceptance criteria

Criteria: a simple list of yes/no statements that outline the desired functionality

Acceptance Criteria are a short list of testable statements that, if true, prove that a piece of software or system does what is required of it: think checklist of things that must happen for a feature or function to be complete.

Acceptance Criteria ensure a shared understanding between the team and the client and define the scope of a feature in yes or no terms. They make it easier to estimate the time and effort required to deliver a feature.

Note: Acceptance Criteria are usually written to help to explain a User Story (see User Story). Ideally, they are written on the back of an index card that has the User Story on the front of the card.

• When picking up a new task or a story to develop, use Acceptance Criteria to define exactly what work is required to be completed for the feature to be successful

1. What is the problem? Discuss the requirements with the team and the client.
2. How do we deliver these requirements? Discuss possible approaches with the team and ask the client, “If X happened, would that mean the problem is solved?” Then list what is needed for “X” to happen.
3. Now refine the list and for each criterion ask, Does this really matter? Could we do less and still deliver value?
4. Finally, rewrite the Acceptance Criteria to be as simple as possible. State things so that they are either true or false, e.g., “Users can submit the form.” That’s either true, or it isn’t.

• Each and every Acceptance Criterion must be a statement that is either true or false. It should not be possible to answer anything other than “Yes, it is satisfied!”, or “No, it is not satisfied!” when you test your work against the statement.
• Acceptance Criteria must be understood by both the client and the team. Because the criteria are the contract between the client and the team, they must be understood by both parties equally well.

• Write Acceptance Criteria in “client” language. An easy way to keep the client focused on what matters to them is by using their own language wherever possible.
• Keep Acceptance Criteria technology agnostic as much as possible.
• Less is more! The point of Acceptance Criteria is to focus the team on achieving that outcome. Having more than ten criteria makes that difficult (see Common Issues).
• Avoid compound criteria. Using “and”, “or”, or other conjunctions in the criteria—even if they are still technically true/false statements— introduces complexity and can lead to confusion.

• Don’t try to cover everything! Focus only on those things that are of value to the client.
• Think about the negative. Client value isn’t always proven only when functionality works as desired: sometimes something not happening is proof of the system working.
• Number your criteria! This makes it way easier to discuss them later.
• Your criteria can be used as the backbone of your test plan. They focus on the most important parts of the feature, so what better parts to test?
• Stuck? Common action words to use in criteria are select, hover, submit, load, click, and view.
• Low-ball. Offer the client a low-fi solution—e.g., a paper form or manual process—because this will help tease out additional requirements.

• Writing Acceptance Criteria for every little thing. There is no point in documenting every characteristic of a solution: many of the things a system will do aren’t important. Try to focus on the key things that represent value to the client, or on the things that represent technical risk and/or complexity. This way your development and testing will focus on what really matters.
• Treating criteria as set-in-stone. Sometimes the criteria you agreed upon don’t quite fit, aren’t clear enough, are unhelpful, or are just plain wrong! Don’t be afraid to challenge, discuss, and update your criteria as you build the feature.
• Too many Acceptance Criteria! Generally, if you end up with more than ten individual Acceptance Criteria, your story is simply too big and you need to break it down (or you are documenting way too much!)
• Untestable criteria. Statements such as, “When cat drinks from dish, it does not tip over” will be difficult to test. How many kitty drinks make this true? One? Five? A million? Keep ’em testable!

1. On this action, this outcome occurs, e.g., When the User selects the map button, the Map is loaded.
2. This feature has this characteristic, e.g., The Map has a default zoom of 14.
3. This feature has this functionality, e.g., The Map view can be zoomed in and out.
4. This user can do this task, e.g., The user can select a location on the Map.