Add Your Heading Text Here
Acceptance criteria
Acceptance criteria are the specific, testable conditions a user story or requirement must meet to be considered complete. They define the boundaries of a piece of work in plain terms, so developers know what to build, testers know what to check, and everyone agrees on what 'done' actually means.
What it means
A user story tells you the goal. Acceptance criteria tell you when it has been reached. They spell out the conditions that have to hold true, ideally as clear pass-or-fail statements with no room for interpretation. Written well, they settle the arguments that otherwise happen at the end of a sprint, when it is expensive to discover that two people pictured 'done' differently.
They also guard against scope creep. If a behavior is not in the acceptance criteria agreed at the start, it is a new request, not a quiet addition midway through. In Azure DevOps, teams often capture acceptance criteria directly on the user story or product backlog item, so they travel with the work and feed straight into testing.
In practice
For a story about resetting a password, the acceptance criteria might read: the user receives a reset email within one minute, the link expires after 24 hours, and the new password must meet the strength rules. A tester can check each line and answer yes or no, with nothing left to opinion.
Häufig gestellte Fragen
What is the difference between acceptance criteria and definition of done?
How should acceptance criteria be written?
Manage requirements the modern way
Modern Requirements brings documentation, traceability, and reviews together inside Azure DevOps.
