Define Acceptance Criteria before Building a Feature

A practical approach

Step 1

State the user’s goal and the condition under which the feature is used. Write the expected visible outcome.

Step 2

Add relevant error, empty and permission cases. Include behaviour when the user repeats or interrupts an action.

Step 3

Review the criteria with the people who will accept the work. Turn ambiguous words such as ‘fast’, ‘easy’ and ‘secure’ into specific expectations where possible.

Worked example

For blog filtering, acceptance criteria can say that selecting a topic updates the result count, resets pagination and shows a clear empty state when the query has no matches. ‘Add a modern filter’ leaves those behaviours undefined.

A mistake to avoid

A checklist of implementation tasks is not the same as acceptance criteria. ‘Create a component’ says what a developer will do, not what the user will experience.

Try it yourself

Write criteria for a resource-download feature using normal, missing-resource and unauthorized cases. Ask a reviewer to decide whether each can be checked without reading the implementation.

Your implementation checklist

• Criteria describe observable behaviour.
• Important boundary cases are included.
• Ambiguous quality words are clarified.
• The reviewer can assess completion independently.