How do you define and write good acceptance criteria for a software feature?

What acceptance criteria actually do

Acceptance criteria (AC) close the gap between what a stakeholder imagines and what an engineer builds. They give QA a test script, give developers a clear finish line, and give product managers a basis for sign-off. Without them, "done" means something different to every person on the team.

The two most common formats

Given / When / Then (Gherkin-style)

This is the most widely used format because it maps directly to automated tests:

• Given a context or starting state
• When the user takes an action
• Then the system produces a specific, observable result

Example: Given a logged-in user with items in their cart, When they apply a valid discount code, Then the order total is reduced by the correct percentage and the code is shown as applied.

Checklist / rule-based format

For simpler features, a bulleted list of rules works well: "The password field must accept 8–64 characters," "An error message appears if the field is left blank," "The form does not submit until all required fields are valid." Each bullet must still be independently testable.

Five rules for writing AC that actually work

1. Write them before development starts. AC written after the fact are rationalizations, not requirements.
2. Make each criterion binary. It either passes or it doesn't. Avoid vague words like "fast," "user-friendly," or "should generally."
3. Cover edge cases and failure paths. What happens when the API is down? When the input is invalid? When a user hits a rate limit?
4. Keep scope tight. One criterion = one behavior. If a single bullet covers three things, split it.
5. Get sign-off from all parties. Product, engineering, and QA should all agree before a ticket enters the sprint. Disagreements caught here cost minutes; disagreements caught in staging cost days.

What to include beyond the happy path

Common mistakes

• Writing AC that describe the UI rather than the behavior ("There is a blue button" vs. "The user can submit the form")
• Confusing acceptance criteria with implementation tasks — AC describe outcomes, not how to build them
• Leaving performance and accessibility as afterthoughts instead of explicit criteria

At CodeNicely, AC are written collaboratively during sprint planning and treated as the contract between product and engineering — it's one of the practices that keeps MVPs shipping in 4–6 weeks without costly late-stage rework.