User Stories: Template, Acceptance Criteria & INVEST

A user story is a short, informal description of a feature written from the end user's perspective, focusing on WHO needs it and WHY, deliberately leaving HOW to implement it up to the development team.

The Standard Template

As a [role],
I want [goal],
so that [benefit].

Example:
As a registered user,
I want to reset my password via email,
so that I can regain access to my account if I forget it.

The "so that" clause explains the underlying VALUE -- understanding
WHY can occasionally reveal a simpler solution satisfies the same need.

Acceptance Criteria: A Concrete Definition of Done

Story: As a registered user, I want to reset my password via email...

Acceptance Criteria:
- User receives a reset email within 1 minute of requesting it
- The reset link expires after 24 hours
- An invalid/expired link shows a clear error message
- The new password must meet the app's standard password requirements

Given/When/Then format makes criteria directly verifiable:
Given a logged-out user,
When they click 'forgot password' and submit a valid email,
Then a reset email is sent within 1 minute.

INVEST: Qualities of a Good Story

• Independent -- not tightly coupled to another story's implementation.

• Negotiable -- a starting point for conversation, not a locked-in contract.

• Valuable -- delivers real value to a user or the business.

• Estimable -- the team has enough information to size it.

• Small -- fits comfortably within a single sprint.

• Testable -- has clear, verifiable acceptance criteria.

Avoid Prescribing Implementation

WEAK: As a user, I want a dropdown menu with 5 options.
(locks in a UI decision before exploring the actual need)

BETTER: As a user, I want to filter results by category,
so that I can find relevant items faster.
(leaves room to choose the best UI pattern -- dropdown,
checklist, search-as-you-type -- during design)