Writing SaaS acceptance criteria that a team can actually test

Turn adjectives into examples

For a fictional contact-import feature, “easy upload” leaves important questions unanswered. Specify supported input, required fields, duplicate handling and error reporting. Keep the business rule separate from the screen layout so a polished prototype does not conceal an unresolved data decision.

Cover success, rejection and repetition

State the exclusions too. Fuzzy matching, enrichment and ongoing synchronisation are separate commitments. The team cannot estimate a bounded import if stakeholders quietly assume all three are included.

Use the same examples throughout delivery

Review criteria before implementation and demonstrate against them afterwards. When a rule changes, retain the reason alongside the new expectation. A screenshot proves little about permission checks or persisted data; inspect the outcome through the relevant workflow.

Should every criterion become an automated test?

Automate important invariants and expensive regressions. Keep human evaluation for wording, comprehension and interaction quality. A short set of representative cases is more usable than an enormous speculative checklist. Add exceptions when evidence reveals them, and keep a named product owner available to resolve ambiguous outcomes before they become conflicting implementations.

Make date conventions part of the example

For an English-language scheduling product, include a date that is ambiguous across regional formats and a participant in another time zone. State the expected displayed date and stored instant. These examples expose ambiguity that a generic successful-booking criterion misses.

Examples are educational and do not describe client results. Content prepared with AI assistance; see our editorial policy. Our method ↗