Acceptance criteria
Acceptance criteria are the conditions a piece of work has to satisfy before users and the business can call it finished. They are written before development, attached to a user story or a spec, and phrased so that anyone can check them with a clear yes or no. A common format is Given / When / Then: a starting situation, an action, an observable result.
Why it matters for a PM
Acceptance criteria are where the ambiguity in a spec gets resolved before it turns into rework. They give developers and testers a shared definition of done, and they help AI coding agents just as much, since agents follow explicit, verifiable conditions far better than intentions. For a PM, writing them is also a way to discover edge cases early.
Example
For a password reset story: “Given a user with a verified email, when they request a reset, then they receive a link valid for 30 minutes.” Another criterion covers the edge case: “Given an unknown email, when someone requests a reset, then the page shows the same neutral message.”
Key points
- Each criterion describes observable behavior, not an implementation.
- Cover the main path, the edge cases (empty, too long, no permission) and the error states.
- Expectations about speed or accessibility need measurable thresholds.
- Criteria written as Given / When / Then map directly to automated tests.
Common mistakes
- Writing criteria nobody can verify, such as “the page is intuitive”.
- Describing the solution in detail and leaving out the expected result.
- Adding criteria once development has started, without discussing the impact on scope.
Go further with Module
The courses and lessons that cover this concept: