Acceptance criteria are the bridge between a product manager's intent and an engineer's implementation. Without them, "done" is subjective — the PM thinks the feature works one way; the engineer implemented it another; QA is unsure which is correct. Acceptance criteria eliminate this ambiguity by defining verification conditions in advance, before a line of code is written.
Acceptance criteria serve three audiences: engineers (who use them to understand the boundaries of the implementation), QA engineers (who write tests against them), and product managers (who use them to verify the implementation matches the spec at review time). A well-written acceptance criterion is unambiguous to all three audiences.
The Gherkin format (Given / When / Then) was developed for behavior-driven development (BDD) and is now widely used even by teams that are not running formal BDD processes. Its structure forces specificity: Given establishes the precondition or context; When describes the action that triggers the behavior; Then describes the expected outcome. This three-part structure prevents the most common acceptance criteria failure mode: describing outcomes without specifying the context they apply to.
Research from engineering teams that track mid-sprint PM clarification requests finds that tickets with 3+ specific acceptance criteria generate 72% fewer clarification requests than tickets without them. The time investment in writing acceptance criteria before the sprint pays back during the sprint in uninterrupted engineering time.
Acceptance criteria vs definition of done vs exit criteria
Acceptance criteria: Specific conditions defined per user story or ticket that describe what must be true for that story or ticket to be considered complete. Written by the PM in collaboration with QA and the tech lead. Example: "Given a logged-in user, when they click Generate PRD, then a 10-section PRD is returned within 30 seconds."
Definition of Done (DoD): A team-level standard that applies to all tickets, not just one. The DoD typically includes: code reviewed, unit tests written, integration tests passing, documentation updated, accessibility checked, performance benchmarks met. A ticket must satisfy both its specific acceptance criteria AND the team's Definition of Done to be truly complete.
Exit criteria: Conditions that must be met to exit a phase of development — sprint exit, QA exit, beta exit. Exit criteria are broader than acceptance criteria and often include business readiness conditions: support team trained, rollback plan confirmed, metrics instrumented. Used more in enterprise and waterfall-influenced environments.
How to Use Acceptance Criteria in Product Management
Write acceptance criteria at two levels:
Story-level criteria (in the PRD's user stories section): 3–5 high-level conditions that define when the overall user story is satisfied. These are written from the user's perspective. Example for "user can receive Slack notifications": (1) Admin receives notification within 2 seconds of status change. (2) Notification includes PRD title, status change, and direct link. (3) Admin can configure which status changes trigger notifications.
Ticket-level criteria (on the engineering ticket): 3–5 specific conditions for each engineering ticket derived from the user story. These are more technical. Example for "Build Slack delivery service" ticket: (1) Given valid Slack OAuth token, when status change event fires, then webhook is called within 500ms. (2) Given revoked Slack token, when delivery attempt fails, then system logs error and falls back to in-app notification. (3) Given delivery service is down, when webhook call times out after 5 seconds, then event is added to retry queue with exponential backoff.
Avoid these common mistakes: (1) "Feature works correctly" — not verifiable. (2) "UI looks good" — subjective. (3) "Performance is acceptable" — no number. (4) "Edge cases are handled" — name the edge cases. Every acceptance criterion should be testable by someone who was not in the product design discussions.
Acceptance Criteria Examples
1Acceptance criteria: user authentication
User story: 'As a new user, I want to sign in with Google, so that I can access Scriptonia without creating a new password.' Acceptance criteria: (1) Given a valid Google account, when the user clicks 'Sign in with Google', then they are authenticated and redirected to the dashboard within 3 seconds. (2) Given a Google account with an email domain not on the allowlist, when they attempt to sign in, then they see an error message: 'Your organization has not enabled Scriptonia access — contact your admin.' (3) Given a revoked Google OAuth token, when the user's session expires, then they are redirected to the login page with a message: 'Your session has expired — please sign in again.' (4) Given a first-time Google sign-in, when authentication succeeds, then a new Scriptonia account is created and the user is shown the onboarding flow.
2Acceptance criteria: data export
User story: 'As a PM, I want to export my PRD as a Markdown file, so that I can share it with stakeholders who don't use Scriptonia.' Acceptance criteria: (1) Given a completed PRD, when the user clicks 'Export Markdown', then a .md file is downloaded within 2 seconds containing all 10 PRD sections with proper Markdown formatting. (2) Given a PRD with images or diagrams, when exported to Markdown, then images are exported as relative file paths or base64-encoded inline. (3) Given a free plan user, when they export a Markdown file, then the footer of the document includes a watermark: 'Created with Scriptonia — scriptonia.dev'. (4) Given a Pro+ user, when they export a Markdown file, then no watermark is added.
3Acceptance criteria: error state
User story: 'As a user, I want to understand why my PRD generation failed, so that I can fix the issue and retry.' Acceptance criteria: (1) Given a PRD generation request that times out after 30 seconds, when the timeout occurs, then the user sees: 'Generation timed out — this sometimes happens with complex briefs. Try simplifying your constraints and try again.' with a 'Try again' button that pre-fills the previous inputs. (2) Given a network error during generation, when the error occurs, then the error is logged with a reference ID and the user sees the reference ID with a message to contact support if the issue persists. (3) Given a retry within 10 seconds of a timeout, when the user clicks 'Try again', then the system implements a 5-second delay before re-sending the request.
How Scriptonia Automates This
Scriptonia generates 3–5 acceptance criteria per engineering ticket automatically, in Gherkin format (Given / When / Then). For a typical PRD with 10 engineering tickets, Scriptonia produces 30–50 acceptance criteria — coverage that would take 2–3 hours to write manually.
The acceptance criteria are included in the ticket description and pushed to Linear, Jira, or GitHub Issues as checklist items. Engineers check them off during implementation; QA verifies them at review. The criteria are derived from the user stories and the edge cases sections of the PRD, creating a consistent chain from user intent to verifiable implementation.