Agile teams often employ user stories to organize project requirements. When using physical index cards to assemble requirements, teams use the backs of the cards to capture acceptance criteria—also called conditions of satisfaction, or just ACs. Acceptance criteria are the main points or general rules to consider when coding and testing the user story.
ACs are not acceptance tests. Professional testers can elaborate these criteria later to produce test scripts. Test scripts, whether automated or manual, are detailed and specific, and they certainly require more space then an index card!
As with the story on the front of the card, the finite amount of space on the back of the card limits writing. That is deliberate. Stories shouldn’t contain every last detail—far from it. In elaborating the stories and writing the tests, coders and testers should continue having conversations with each other and the business representatives.
Teams using electronic systems may also record acceptance criteria there, but without the limits imposed by physical cards, these teams have to resist the temptation to add more and more detail. Remember: A story is a placeholder for a conversation. Resist the urge to get detailed in ACs.
Acceptance Criteria and Testers
ACs expand on the initial story, so they are usually written by the same person who wrote the original story—probably the business representative or product owner (PO). However, when a PO is short on time, ACs are frequently dropped. That is not always a bad thing, but it may well be the sign of a problem. Testers might need step in to add acceptance criteria themselves.
Usually, testers begin their work with existing ACs. They may give feedback to the PO on how to improve the criteria, but their main role is to take the ACs and create actual tests from them. Hopefully these tests are automated, but if not, they will be natural language descriptions of how to perform the tests.
The story and ACs form the requirement; the tests form the specification. Requirements describe what the business wants to achieve, while specifications describe the detailed parameters within which the solution needs to perform. Specifications always need to be testable. Techniques such as specification by example and acceptance test-driven development make specifications themselves executable as automated tests.
If it helps product owners to talk to testers or programmers when writing stories and acceptance criteria, then they should. And if it helps testers to write tests by talking to the programmers and POs, they also should. Teams that encourage such collaboration sometimes call these discussions “Three Amigos” or the “Power of Three.” In these conversations, people representing requirements, testing, and coding come together to talk about the story. Not only will they discuss the story and ACs, but they also may change them, add to them, or split the story into multiple smaller stories.
The Level of Detail
Consider this example:
As a delivery company, I want to have the customer’s full postal address on packages so that I can deliver them correctly.
Such a story might have ACs like:
Customers must provide a valid postal address
Shipping labels must carry a correctly formatted address
Notice that a “valid postal address” is not defined. That kind of detail can be left until later, as ACs are not the place to elaborate. (An exception might be when some nonobvious detail is important, say, using all nine digits of the ZIP code.)