Acceptance Criteria Types
Acceptance Criteria Types define what must be achieved for a project to be considered complete in Agile project management.
Acceptance Criteria Types are the distinct categories of conditions that acceptance criteria commonly fall into based on what aspect of a story's behavior they constrain, ranging from functional correctness to performance, usability, and error handling. Recognizing these types helps a team writing acceptance criteria systematically check that they have covered the different dimensions along which a story could be judged complete, rather than focusing narrowly on only the most obvious functional behavior and overlooking equally important but less visible conditions.
Functional Criteria
Defining Correct Behavior
Functional criteria specify the core behavior a story must exhibit under normal conditions, describing what the system should do in response to a given action or input.
The Primary Path
Functional criteria typically begin with the story's main intended use case, the behavior most directly tied to the story's stated value, before extending to variations and exceptions.
Boundary and Edge Case Criteria
Testing the Limits
Boundary criteria specify expected behavior at the extremes of valid input or usage — the smallest or largest allowed value, an empty input, a maximum limit — where subtle defects are most likely to occur.
Distinct from the Common Case
These criteria are deliberately separated from ordinary functional criteria because edge conditions often require special handling that would otherwise be overlooked if only typical scenarios were considered.
Error and Exception Criteria
Specifying Failure Behavior
Error criteria define how the system should respond when something goes wrong — invalid input, a failed dependency, an unauthorized action — ensuring failure states are handled deliberately rather than left undefined.
Communicating Failure to Users
Many error criteria specify not just that an error is detected internally but how it should be communicated to the user, since a technically correct failure with a confusing or missing message can still represent an incomplete story.
Performance Criteria
Quantifying Acceptable Speed and Load
Performance criteria specify measurable thresholds for response time, throughput, or resource usage under defined conditions, translating general nonfunctional expectations into story-specific, testable standards.
Usability Criteria
Standards for User Experience
Usability criteria describe expectations around ease of use, discoverability, or accessibility, ensuring the story's implementation is not just functionally correct but genuinely usable by its intended audience.
Often Expressed as Observable Behavior
Because usability can be subjective, criteria in this category are typically framed around specific, observable standards — such as a maximum number of steps to complete a task — rather than vague appeals to a good experience.
Security and Compliance Criteria
Protecting Data and Access
Security criteria specify required protections around authentication, authorization, or data handling relevant to the story, ensuring these concerns are addressed explicitly rather than assumed to be handled elsewhere.
Satisfying External Obligations
Where a story touches a regulatory or contractual obligation, compliance criteria translate that broader obligation into specific, testable conditions applicable to the story at hand.
Data Integrity Criteria
Ensuring Consistency and Accuracy
Data integrity criteria specify conditions ensuring that information is stored, updated, or displayed accurately and consistently, particularly important for stories involving data creation, modification, or synchronization across systems.
Visualizing the Range of Criteria Types
Each surrounding category represents a distinct lens through which the story's completeness can be examined, helping the team avoid focusing narrowly on functional behavior alone.
Applying Criteria Types During Formation
Using Types as a Checklist
Reviewing each relevant category systematically during acceptance criteria formation helps a team catch dimensions of the story that might otherwise be overlooked in an unstructured discussion.
Not Every Story Requires Every Type
Not all categories apply to every story; a purely internal technical change may have no meaningful usability criteria, while a public-facing feature may have limited data integrity concerns, so relevance is judged per story rather than applied uniformly.
Risks of Narrow Criteria Coverage
Overlooking Nonfunctional Expectations
Focusing acceptance criteria solely on functional correctness risks delivering a story that technically works but performs poorly, handles errors confusingly, or fails to meet security expectations.
Late Discovery of Missing Criteria
Gaps in criteria coverage are often discovered only after delivery, when a missing edge case or performance issue surfaces in production, at a point where correction is considerably more costly.
Benefits of Recognizing Criteria Types
More Complete Stories
Systematically considering each relevant category produces acceptance criteria that address the full range of expectations a story should satisfy, not just its most visible functional behavior.
Better Test Design
Clear categorization of criteria types supports more structured, comprehensive test design, since each type suggests specific kinds of test cases to construct.
Fewer Post-Delivery Surprises
Addressing performance, security, and error-handling expectations explicitly during criteria formation reduces the likelihood of discovering significant gaps only after the story has already been delivered.