Acceptance Criteria and Traceability
A feature is "done" only if everyone agrees on what it was supposed to do. Acceptance criteria make that agreement explicit: concrete, testable conditions a piece of work must satisfy before it is accepted. Written well, they expose misunderstandings before code is written, give testers and developers the same target, and become automated tests that keep the behavior working.
Traceability extends that link over time. When a regulation changes, a customer disputes behavior, or a requirement is revised, you need to know which tests verify it, which code implements it, and which releases contain it. Regulated industries require formal traceability; every team benefits from a lightweight version.
TL;DR
- Acceptance criteria are specific, testable conditions for a requirement or story — not implementation instructions.
- Write them as rules, Given-When-Then scenarios, or example tables; include negative paths and quality attributes.
- Agree on criteria before development, with product, engineering, and testing together.
- Definition of Done applies to all work; acceptance criteria are specific to each item.
- Traceability links needs → requirements → acceptance criteria → tests → code → releases, in both directions.
- Use it for change impact analysis: when a requirement changes, find every affected test, component, and release.
Quick Example
Acceptance criteria as executable scenarios, tagged with the requirement they verify:
The same link in a code-level test, so a report can list every test for REQ-142:
Register the custom requirement marker in pytest configuration, and generate a traceability report from markers and feature tags in CI.
Core Concepts
Writing Acceptance Criteria
Good criteria are testable (someone can decide pass or fail), unambiguous (numbers, states, and roles named precisely), outcome-focused (what the user or system observes, not how it is built), and complete enough to cover error cases and boundaries.
Specification by Example
Concrete examples clarify rules far better than abstract statements. "Refunds above the limit need approval" invites questions; examples at $199.99, $200.00, and $200.01 answer them. Collaborative sessions where product, engineering, and testing work through examples — sometimes called example mapping or the "three amigos" — surface edge cases before development.
Negative Paths and Quality Attributes
Criteria should cover what must not happen and how the system behaves when things go wrong: invalid input, missing permissions, timeouts, partial failures. Include relevant quality attributes — response times, accessibility, audit logging, data retention — when they matter for the item. See Quality Attributes and Nonfunctional Requirements.
Definition of Done Versus Acceptance Criteria
Traceability
What Gets Linked
Forward traceability answers "is every requirement implemented and tested?" Backward traceability answers "why does this code or test exist?" Both are needed for impact analysis.
A Traceability Matrix
Generated automatically from tags, test results, and issue links, the matrix stays current; maintained by hand in a spreadsheet, it rarely does.
Change Impact Analysis
When REQ-142's limit changes from $200 to $300, traceability shows the scenarios and tests to update, the components that implement the rule, the documentation and training material that mention it, and the releases that contain the old behavior. Without links, teams search code and hope.
Lightweight Versus Formal Traceability
Start lightweight; add formality where regulation, safety, or contracts require it.
Best Practices
Agree on Criteria Before Building
Review acceptance criteria with product, development, and testing before work starts; most defects found later trace back to criteria nobody questioned.
Automate the Criteria That Matter
Turn key scenarios into automated tests at the right level — unit, integration, or end-to-end — so the agreed behavior is continuously verified. See Integration Testing.
Use Stable Identifiers
Give requirements stable IDs and reference them consistently in tests, commits, and pull requests, so links can be generated automatically.
Keep Criteria and Tests in Sync
When behavior changes, update the criteria and tests in the same change. Living documentation is only valuable if it is true. See Change Management.
Common Mistakes
Vague Criteria
Implementation Instead of Behavior
Happy Path Only
FAQ
What are acceptance criteria?
Specific, testable conditions that a user story or requirement must meet to be accepted, describing expected behavior — including edge cases and errors — rather than how it is implemented.
What is the Given-When-Then format?
A way to write scenarios: Given describes the starting context, When describes the action or event, and Then describes the expected outcome. It is used in behavior-driven development and maps naturally to automated tests.
What is requirements traceability?
The ability to follow links from a requirement to its acceptance criteria, tests, implementation, and releases — and back — to verify coverage and analyze the impact of changes.
Do agile teams need traceability?
A lightweight form, yes: linking tickets, tests, and code through IDs makes impact analysis and audits easier. Formal traceability is required mainly in regulated and safety-critical domains.
Who writes acceptance criteria?
Typically the product owner or manager drafts them, refined collaboratively with developers and testers before development so they are clear, complete, and testable.
Related Topics
- Requirements Engineering — Eliciting and managing requirements
- Quality Attributes and Nonfunctional Requirements — Criteria beyond functionality
- Testing — Turning criteria into tests
- Integration Testing — Verifying behavior across components
- Product Management — Defining what to build
- Change Management — Controlling changes to agreed behavior