User Stories and Acceptance Criteria

What are user stories and acceptance criteria?

A user story is a lightweight requirement description written from the perspective of the end user, focusing on the value they receive - not the technical implementation. User stories are placeholders for a conversation, not complete specifications.

The Format

As a [type of user]
I want to [perform some action]
So that [I achieve some goal/value]

Examples:

• As a registered user, I want to reset my password via email so that I can regain access to my account.
• As a Pro subscriber, I want to see detailed AI explanations for each question so that I can understand why my answer was wrong.

The "so that" clause is the most important part - it states the business value and prevents building features nobody needs.

INVEST Criteria

Good user stories are INVEST:

Letter	Quality	Meaning
I	Independent	Can be delivered without depending on other stories
N	Negotiable	Details to be discussed, not a fixed contract
V	Valuable	Delivers value to a user or customer
E	Estimable	Team can estimate the effort
S	Small	Fits in a sprint; can be completed in days
T	Testable	Clear acceptance criteria - we can verify it's done

Acceptance Criteria

Acceptance criteria (AC) define the conditions that must be satisfied for the story to be accepted as done. Two common formats:

Given-When-Then (BDD)

Given a registered user with a verified email
When they click "Forgot Password" and submit their email
Then they receive a password reset email within 2 minutes
And the link in the email is valid for 1 hour
And clicking the link opens a form to enter a new password

Checklist Format

- User receives email within 2 minutes
- Reset link expires after 1 hour
- Form validates new password meets requirements (min 8 chars)
- After reset, user is redirected to login
- Old sessions are invalidated after reset

Acceptance criteria serve dual purpose: define completion for the developer and define test cases for QA.

Story Points

Relative effort estimates assigned to stories using a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21). Points represent relative complexity and effort - not hours.

Benefits of relative estimation:

• Faster than hour estimation
• Accounts for uncertainty (a 13-point story is uncertain, not just large)
• Teams improve at relative estimation faster than absolute

Planning Poker: each team member independently picks a card; reveal simultaneously; discuss outliers. Consensus-based estimation.

Epics and Story Decomposition

• Epic: a large user story too big to fit in a sprint. Decomposed into smaller stories.
• Feature: a group of related stories delivering a significant product capability.
• Task: technical subtask within a story (not visible to users; used internally by developers).

Decompose epics by: user type, happy path vs edge cases, CRUD operations, platform (mobile/web), or workflow steps.

Story vs Requirement

User Story	Traditional Requirement
Conversation trigger	Complete specification
Written by/with users	Written by analysts
Small, testable slice	Can be large, vague
Context: why (value)	Context: what (function)
Iterative refinement	Sign-off then freeze

Definition of Ready

A checklist for stories before they enter a sprint:

• Acceptance criteria written and agreed
• Estimated by the team
• Dependencies identified
• UI designs available (if needed)
• Technical approach discussed

"Ready" prevents a team from pulling in an incomplete story and discovering mid-sprint that it's blocked.

Interview Angle

User stories appear in architecture interviews when discussing requirements and team collaboration. Key points: the "so that" clause ensures business value, acceptance criteria define testability, and story points enable velocity tracking for sprint planning. Show you understand the difference between a story (user value, conversation trigger) and a task (technical implementation detail). In senior roles, demonstrating how to decompose an epic into deliverable stories shows product thinking.