HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Precision in Product

Defining what 'done' actually means.

⚡ Total XP: 0|💻 management XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.

🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.

Ambiguity is the single most expensive thing in a sprint — acceptance criteria are how you remove it before code gets written.

1Why 'It Works' Isn't Enough

A story that just says 'add a login form' invites a different implementation from every engineer who picks it up. Acceptance criteria force the conversation about edge cases, error states, and validation rules to happen during refinement, not during a bug report three weeks after launch.

2Writing Criteria the Team Will Actually Use

Good AC are short, specific, and testable — usually 3 to 6 bullet points per story. If a criterion needs a paragraph to explain, it's probably describing an implementation detail rather than an observable behavior, and it belongs somewhere else.

3Step-by-Step Breakdown

Introduction. Acceptance Criteria (AC) are the specific, testable conditions a user story must satisfy to be considered complete. Without them, 'done' is whatever the last person in the room decided.

The Given/When/Then Format. The most common structure is Given/When/Then: GIVEN a starting context, WHEN an action happens, THEN an outcome is expected. This BDD-style phrasing turns vague requirements into something QA can actually check off.

Covering the Unhappy Path. The main flow is the easy part. Strong acceptance criteria also spell out edge cases: what happens with an invalid email, an expired session, or a network timeout. If it isn't in the AC, engineering will guess.

Knowledge Check. Why must an acceptance criterion be binary (pass or fail), not open to interpretation?

→So QA and engineering can objectively verify the story is complete without ambiguity
→So the criteria can be copy-pasted into the API documentation

Summary. Acceptance Criteria are a contract between Product and Engineering. Write them before development starts, not as an afterthought during QA.

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Writing implementation details instead of behavior

// Wrong
GIVEN a signup form, THEN store the email in a Postgres table with a unique constraint

// Correct
GIVEN a signup form, WHEN an email already exists, THEN show 'This email is already registered'

The Solution //

'Use a PostgreSQL unique index on email' is an implementation choice, not an acceptance criterion. AC should describe observable outcomes so engineering retains the freedom to choose how to build it.

The Error //

Only covering the happy path

// Incomplete
GIVEN valid input, WHEN user submits, THEN show success

// Complete
GIVEN valid input, WHEN user submits, THEN show success
GIVEN the network request fails, WHEN user submits, THEN show a retry option

The Solution //

If every criterion assumes the user does everything right, QA has no basis to flag missing error handling — and it ships broken. Always include at least one failure or edge-case scenario per story.