Writing Acceptance Criteria That Stick to Requirements

Acceptance criteria are the difference between a requirement that sounds good in a meeting and one a developer or QA person can actually test. After you draft a PRD section and list its requirements, you need acceptance criteria for each one—concrete, observable statements of what "done" looks like. This step is where most teams lose precision. Vague criteria lead to rework. Criteria that drift from the requirement create arguments. This guide shows you how to write them correctly, spot the mistakes people make, and verify the result before you move forward.

What Acceptance Criteria Are For

An acceptance criterion is a single, testable statement describing behavior the software must exhibit or a condition it must meet. Not a goal. Not a nice-to-have. Not a design suggestion. A criterion answers the question: "How will we know this requirement is satisfied?"

A requirement might be: "Users can export their data." The acceptance criteria are: "When a user clicks the Export button, the app generates a CSV file within 5 seconds" and "The CSV includes all fields from the user's profile and transaction history" and "The file downloads to the user's default download folder." Each one is testable. Each one is tied to the requirement. Each one can be checked in code review or QA.

If your criteria are written well, your team will not argue about whether the work is done. If they are vague—"the system is fast" or "users find it intuitive"—you will rework the same feature three times.

Common Mistakes in Acceptance Criteria

Mistake 1: Criteria that describe the design instead of the behavior. A requirement says "Improve the login flow." A criterion reads: "Add a password strength meter to the password field." That is a design decision, not a testable outcome. A better criterion: "If password length is fewer than 8 characters, display a red warning icon; if 8 or more, display a green checkmark; update in real time as the user types."

Mistake 2: Criteria that are too broad or use undefined terms. "The system should be reliable" or "Ensure a smooth user experience" are not criteria. They cannot be tested. Replace them with measurable statements: "API calls succeed in under 2 seconds for 99% of requests" or "Form submission completes without requiring the user to scroll back up."

Mistake 3: Criteria that hide assumptions."The system should work for all users" assumes you know who "all users" are. Better: "The feature works on Chrome 90+, Firefox 88+, Safari 14+, and Edge 90+" or "The feature works for users on both desktop and mobile devices running Android 10 or later and iOS 13 or later."

Mistake 4: Criteria that are longer than a sentence or bundle multiple behaviors. Criteria are not essays. If you use the word "and" more than once, split it into separate criteria. "Users can log in via email or phone, and the system validates the input and sends a confirmation code" should be three criteria: one for email login, one for phone login, one for validation and confirmation.

Mistake 5: Criteria that drift from the source requirement. If your PRD requirement is quoted directly from a customer interview, your criteria should stay anchored to that quote. If the requirement says "Users report duplicate transactions" and your criterion says "The system auto-detects and hides near-identical entries," you have moved into solution territory and may be solving a different problem than the customer described.

How to Write Acceptance Criteria

Start with your requirement statement. Read it aloud. Ask: "What would I actually observe or test to know this is true?" Write that down. Then check it against these four rules.

Rule 1: Use if-then or given-when-then structure. "If the user enters a password with fewer than 8 characters, then a red warning appears" or "Given a user is logged in, when they navigate to Settings, then their saved preferences load within 2 seconds." This structure forces you to be specific about the condition and the outcome.

Rule 2: Avoid adjectives like "easy," "fast," "intuitive," "simple." These words mean different things to different people. Replace "fast" with a number: "loads in under 2 seconds." Replace "intuitive" with a behavior: "new users can complete a purchase without reading documentation." Replace "easy" with a measurement: "requires no more than three clicks."

Rule 3: Include a boundary or edge case. Don't just test the happy path. For a requirement "Users can upload a file," add a criterion: "If the file size exceeds 50 MB, the system displays an error message and does not proceed." For "Users can set a reminder," add: "If the reminder date is in the past, the system displays an error message." This catches oversights in implementation.

Rule 4: Anchor the criterion to the requirement."" If your requirement came from a customer quote, your criterion should reference that quote in a comment or tag. Example: "[REQ-2.3, 'Users report duplicate transactions'] — When a user views their transaction history, any two transactions with identical amount, date, and merchant are marked with a "duplicate" label." This makes it easy to trace the work back to the customer's actual pain point.

How to Check Your Criteria Before You Hand Them Off

Before you declare the acceptance criteria done, run this checklist.

• Read each criterion aloud. If it sounds like a design decision or an opinion, rewrite it as a behavior or measurement.
• Ask a developer or QA person to read them. Can they write a test or test case from each criterion without asking you for clarification? If not, the criterion is incomplete.
• Check for the word "and." If you use it more than once per criterion, split into separate criteria.
• Verify each criterion is tied to the requirement. Point back to the requirement. If you cannot trace the criterion to the requirement statement, it may be drift.
• Look for unmeasurable words. Search for "good," "fast," "user-friendly," "intuitive," "reliable," "seamless." Replace each with a measurement or observable behavior.
• Test the criteria against edge cases. Ask: "What if the input is empty? What if it is too large? What if the user is offline? What if the user has no permissions?" If your criteria do not address at least one edge case per requirement, add one.

When to Know You Are Done

Acceptance criteria are done when a developer or QA person could hand your criteria to someone who has never seen your PRD and that person could write code, run tests, or validate the feature without talking to you. If you pass that test, you are ready to move to the next step in your PRD process.

Originally published at Forged Goods. The ready-made version: Customer Interview → PRD Prompt Pack.