Acceptance Criteria

Acceptance criteria (AC or ACs for short) seem to be among the most feared and neglected concepts in Scrum, and I’m not sure why. The best way to understand them is by comparing Acceptance Criteria to a Story statement. A properly formed Story statement looks like this:

As a {someone} I want to {do something} in order to {accomplish some result}.

Such as:

As a Cashier, I want to enter a Product Code, in order to add it to a Purchase Transaction.

You may simplify the format:

Add Item to Purchase Transaction by entering a Product Code.

Sticklers will claim that the stricter format shapes our thinking and forces us to identify all three aspects of the Story. Sure. But there are other things missing from the Story statement that are far more critical. For example, what happens in our example if the Cashier enters an invalid Product Code? The answer to that question is commonly known as a “business rule.” Sometimes, it takes more than one BR to answer the question:

  1. If a Cashier enters an invalid Product Code, display an error message, “Invalid Product Code.”
  2. If a Cashier enters an invalid Product Code, ask the Cashier whether they need to enter an override.

Each business rule becomes an Acceptance Criterion, an action that causes a verifiable result, all of which are variations of the Story’s “happy path.” The ACs should cover all the action/response pairs possible within the context of the Story:

  1.  If a Cashier enters a valid Product Code, add the product to the Purchase Transaction.
  2.  The Cashier must press the Enter key to submit the Product Code.
  3.  The Cashier may use the backspace key to modify the Product Code up to the time they submit.
  4.  A Product Code must be exactly 7 numeric digits.
  5.  If a Cashier enters a nonexistent Product Code, display an error message, “Invalid Product Code: Unknown Product.”
  6.  If a Cashier enters a nonexistent Product Code, ask the Cashier whether they need to enter an override.
  7.  If the Cashier enters a non-conforming Product Code, display an error message “Invalid Product Code: Code Length”, “Invalid Product Code: Numeric Characters Only.”
  8.  After a valid Product Code has been added to a Purchase Transaction, prepare to accept the next Product Code from the Cashier.
  9.  Etc.

The override process referenced in rule 6 would become another Story, as would the undo and cancel actions. Rule 1 above implies another Story:

As a Transaction Entry User Interface, I want to look up an entered Product Code in the product catalog, in order to determine the product Price.

That Story would have its own set of business rules, and hence, ACs.

Whether or not you’ve written Acceptance Criteria into each Story, they must exist, if only in the Product Owner’s head. Someone must know how the application should behave in general, and specifically what to expect from each individual function or action. It’s best to share that information with everyone required to implement and validate that Story. By recording the ACs you force yourself to think through all the possible variations implied by the Story, which multiplies the likelihood of success.

Acceptance Criteria, or Business Rules, if you prefer, are one of the non-negotiable project management techniques. A software engineering team should not be asked to deliver a feature until the Product Owner or Program Manager articulates that feature’s expected behavior, and ACs are the most succinct way to eliminate ambiguity.