User Story
1. 🎯 Goals
What are we trying to achieve?
Outline the high-level business goals and user objectives this feature or project supports.Include any KPIs or success metrics you’re aiming to improve.
Example:
Reduce onboarding drop-off by 20%
Enable SSO login for enterprise users
Shorten support resolution time by automating FAQs
2. 🧭 Context & Problem Statement
Why now? What's the real pain point?
Describe:
The core problem this feature addresses
Why it's a priority now (e.g., market demand, internal OKRs, user complaints)
The business value or user need being met
Example:
Users are abandoning signup due to a multi-step email verification flow. This has become a conversion bottleneck for growth and requires optimization to reduce friction for new users.
3. 👤 User Stories
Use the When → Then → So that format for clarity and testability.
Format:
When [describe the situation or event]
Then [describe the user/system action or response]
So that [explain the benefit or value]
Example User Story:
When a user enters their email and clicks "Reset Password"
Then the system sends a reset link to their inbox
So that they can securely regain access to their account
You can include multiple stories for different user roles or edge cases.
4. 📋 Requirements
✅ Functional Requirements
Specify:
Core features and flows
Expected system behaviors
All necessary user interactions and edge cases
Example:
The system must support both email and phone-based 2FA during login
Users should receive confirmation after successfully updating their settings
🛡 Non-Functional Requirements
Define cross-cutting system qualities such as:
Performance (e.g., load time < 2s)
Security (e.g., GDPR compliant, hashed credentials)
Availability (e.g., 99.9% uptime)
Scalability (e.g., supports 10k concurrent users)
Compliance (e.g., SOC2 readiness)
5. 🚫 Out of Scope
List specific items or features that will not be addressed in this release to prevent scope creep.
Example:
SSO for non-enterprise accounts
Mobile app parity — desktop only for this phase
6. ✅ Acceptance Criteria
Use scenario-based logic to define what “done” looks like. Format like this:
Example: Password Reset Flow
Given the user has a valid email registered
When they initiate a password reset
And click the link in their inbox
Then they are prompted to set a new password
And their password is successfully updated
Include:
Edge cases
Valid/invalid input handling
System errors (e.g., expired link)
Visual feedback expectations
