Do you struggle to communicate the intent of requirements to development teams? Is there frequently misunderstanding, no matter how clear you try to be in defining user stories?
Acceptance criteria are a useful tool to clarify intent. It is common practice to write a set of acceptance criteria for each user story. A set of acceptance criteria specifies the conditions the software must meet before it will be accepted as done.
In other words, they are assertions about behaviour together with clear descriptions stating how to decide whether each assertion passes or fails.
A good set of acceptance criteria can be readily translated into manual or automated test cases.
Acceptance criteria can be functional or non-functional. In both cases, you should state what the expected behaviour is, not how to implement the expected behaviour.
For non-functional requirements, there is no point repeating generic non-functional requirements, which should be negotiated with the team, documented for an entire product and applied equally to all user stories. Examples are target devices and minimum performance standards such as response times. However, any exceptions or departures from generic non-functional requirements should be captured as separate acceptance criteria.
Tips to write better acceptance criteria:
- Every user story should have at least one acceptance criterion (if you cannot write down how to determine if the user story is accepted, how will you accept it?)
- Each acceptance criterion should be independent (in testing terminology: atomic)
- Acceptance criteria focus on the what (intent) not the how (implementation)
- As product manager (/product owner), if you can, explain the user story to the team, then get the team to write acceptance criteria (reviewing the team’s proposed acceptance criteria is an effective way to check for shared understanding)