[Process/Documentation] How do you write acceptance criteria that QA and business users both find useful?

Example Answer

I try to write acceptance criteria so they are specific enough to test and understandable enough to validate. If the criteria only make sense to QA or only make sense to the business, they are usually missing something. I want them tied to the user or process context, the expected behavior, the relevant rule or condition, and the expected outcome.

I also pay attention to ambiguity. Words like "appropriate," "timely," or "correct" often sound fine in a meeting but create different interpretations later. I would rather define the behavior clearly than rely on shared assumptions that may not actually be shared.

When possible, I like to review acceptance criteria with both business and delivery perspectives in mind. If QA cannot test it or the business says it still does not capture the real outcome, it is not ready. Good acceptance criteria are one of the best ways to keep a requirement from becoming three different ideas in three different teams.

Common Poor Answer to Avoid

"I write acceptance criteria mainly so QA knows what to test."

Why it's weak

• It underplays the role acceptance criteria play in aligning the business, engineering, and QA on expected behavior.

Why this works

• It shows acceptance criteria as a shared clarity tool, not just a testing checklist.