Writing Acceptance Criteria That Developers Love

A good requirement reads like a test case and a bad one reads like a wish. After a decade of UAT sessions I have settled on a template that is short enough to actually be used and strict enough to catch the gaps early.

The template

Each criterion has a precondition, an action and an observable result — Given, When, Then — plus the data set it should be run with. If a sentence contains “and/or”, “etc.” or “as appropriate”, it is not finished.

Key points

• One observable outcome per criterion.
• Name the data set and the environment.
• Write the negative paths before the happy path.
• Review criteria with a tester and a developer together.

Examples beat adjectives

Instead of “the report must load quickly”, write “the daily settlement report for 5,000 transactions renders in under three seconds on the UAT server”. The developer can now measure it and the tester can now fail it.

Example in code

it('rejects a transfer after the end-of-day batch has started', function (): void {
    $this->travelTo('2026-03-01 23:05:00');

    $response = $this->actingAs($teller)->postJson('/api/transfers', [
        'from' => '001-2345-6', 'to' => '001-9876-5', 'amount' => 250_000,
    ]);

    $response->assertStatus(422)->assertJsonPath('code', 'EOD_IN_PROGRESS');
});

Negative paths first

Most defects hide in what should not happen. Rejections, timeouts, duplicate submissions and permission errors deserve their own criteria, written before the happy path so they are never left for later.

A good requirement reads like a test case and a bad one reads like a wish.

Takeaways

Acceptance criteria are the cheapest tests you will ever write. Spend the extra ten minutes making them executable and the whole delivery gets calmer.