Let's transform a vague user story into one with clear acceptance criteria. Consider this basic story: "As a user, I want to reset my password." Without acceptance criteria, team members might interpret this differently. Some might build just the reset mechanism, others might include email notifications, and others might assume security questions are needed.

Here's how different acceptance criteria formats could clarify this story:

Given-When-Then format (Gherkin user stories):

• Given I've forgotten my password, when I click "Forgot password" and enter my email, then I receive a reset link email.
• Given I've received a reset link, when I click it, then I can create a new password.
• Given that I'm setting a new password, when I enter a password with fewer than 8 characters, then I see an error message.^[1]

Checklist format:

• The reset link expires after 24 hours.
• The new password requires at least 8 characters.
• A user receives a confirmation email after a successful reset.
• User remains logged in after reset.

When writing acceptance criteria, start by identifying the main user paths and key system behaviors. Include edge cases and error states. Use active voice and concrete examples. Work with developers to ensure technical feasibility and with designers to align with user experience goals. Revisit and refine the criteria during backlog refinement as understanding evolves.