✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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.

Functional Criterion = Given Condition Expected Behavior

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.

Performance Criterion = Response Time 500 ms

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

Story Functional Boundary/Edge Error/Exception Performance Usability Security

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.