Writing User Stories
A user story is a short, plain-language description of what a user wants to do and why. User stories replace lengthy, technical requirement documents. They keep the focus on the customer's goal rather than the technical implementation.
The Standard User Story Format
Every user story follows this structure:
As a [type of user], I want to [perform some action], so that [I achieve some benefit or goal].
Example: "As a new customer, I want to reset my password by email, so that I can regain access to my account if I forget it."
This one sentence tells the engineer who the feature is for, what it needs to do, and why it matters. Everything the team needs to understand the feature is in that sentence.
Why User Stories Work Better Than Feature Lists
Many teams used to write requirements like: "Add a password reset button on the login page that sends a reset link via email to the registered address."
That is a solution, not a requirement. User stories keep the why in focus. When engineers know why they are building something, they make better implementation decisions on their own.
Adding Acceptance Criteria
The user story alone is not enough for engineers to build the feature. Acceptance criteria define exactly when the story is considered "done." They are the checklist the team uses to verify the feature works correctly.
Format for acceptance criteria (Given / When / Then):
GIVEN: [The user is in a specific situation] WHEN: [The user takes an action] THEN: [A specific result occurs]
Example for the password reset story:
Acceptance Criteria: Given a user is on the login page, When they click "Forgot password" and enter their email, Then they receive a reset link within 2 minutes. Given a user clicks the reset link, When the link is less than 24 hours old, Then they are taken to a page to create a new password. Given a user creates a new password, When the password is at least 8 characters and includes a number, Then their account password updates successfully.
These criteria leave no ambiguity. The engineer, the designer, and the quality tester all look at the same list to confirm the feature is complete.
Epic vs. Story vs. Task
Product work is organized in layers from large to small:
EPIC (Large)
A major area of work that takes multiple sprints
Example: "User Authentication System"
↓
STORY (Medium)
A single user need within the epic, completable in one sprint
Example: "As a user, I want to log in with Google so I can skip creating a password"
↓
TASK (Small)
The specific technical steps to complete the story
Example: "Integrate Google OAuth API" / "Add Google button to login screen"
PMs write epics and stories. Engineers break stories into tasks during sprint planning.
Common Mistakes in User Stories
| Mistake | Problem | Fix |
|---|---|---|
| Too vague | "As a user, I want a better experience" | Name the specific action and outcome |
| Solution-first | "As a user, I want a dropdown menu" | Focus on the user's goal, not the UI element |
| Too big | A story that takes 3 sprints to complete | Split into smaller stories |
| No acceptance criteria | Engineers don't know when it's done | Always add Given/When/Then criteria |
| Wrong user type | "As a user" is too generic | Name the specific user type: "As a first-time buyer..." |
A Practical User Story Template
┌──────────────────────────────────────────────────────┐ │ TITLE: [Short feature name] │ │ │ │ USER STORY: │ │ As a [specific user], │ │ I want to [action], │ │ So that [outcome]. │ │ │ │ ACCEPTANCE CRITERIA: │ │ ☐ Given ___, When ___, Then ___ │ │ ☐ Given ___, When ___, Then ___ │ │ ☐ Given ___, When ___, Then ___ │ │ │ │ PRIORITY: Must Have / Should Have / Could Have │ │ ESTIMATE: [Story points or days] │ │ DESIGN LINK: [Link to mockup if available] │ └──────────────────────────────────────────────────────┘
Involving the Team in Story Writing
The best user stories come from collaboration. PMs draft the story. Designers confirm the experience makes sense. Engineers confirm the story is feasible. Quality testers turn acceptance criteria into test cases. This three-amigo approach (PM + designer + engineer) catches gaps before any code is written.
Key Takeaway
User stories keep the team customer-focused throughout the build process. They replace ambiguous requirements with clear, testable descriptions of value. A well-written user story with solid acceptance criteria removes guesswork from the development process and results in features that customers actually wanted.