How to Write Your First User Story

User stories describe who needs something, what they need, and why.

This guide covers the user story format, acceptance criteria, and common mistakes when describing user needs.

What is a user story?

A user story commonly starts with a short statement that explains:

• WHO needs something (a real person)
• WHAT they need (their goal)
• WHY they need it (the value)

The statement gives the team a starting point for discussing the need. Supporting details and acceptance criteria clarify the scope.

Example: ordering lunch

• Prescriptive: "I want you to use whole wheat bread, slice tomatoes 4mm thick, apply 15g of mayo..."
• User-focused: "I need a healthy lunch that I can eat quickly during my meeting"

Example: a software feature

• Prescriptive: "Create a blue button that calls API endpoint /reset with POST method..."
• User-focused: "As a forgetful user, I want to reset my password, so that I can access my account again"

The user story format

A common user story template is:

As a [type of user]
I want [their goal]
So that [the benefit they get]

What the format captures

The three parts identify the user, their goal, and the benefit. Engineering can use that intent when discussing the implementation.

Write your first story

Step 1: Think of an app you used today. Pick one annoying thing about it.

Step 2: Fill in these blanks:

• As a _________ (what kind of user are you?)
• I want _________ (what would help?)
• So that _________ (why would this matter?)

Example: "As a busy parent, I want to save my shopping list, so that I don't forget items at the store"

Compare story examples

Evolution of a Story

Attempt 1 (Too vague): "As a user, I want a button"

• Problem: What button? Why? Who needs it?

Attempt 2 (Better but prescriptive): "As a user, I want a red download button in the top right"

• Problem: That's a solution, not a need

Attempt 3 (Good!): "As a mobile user, I want to download articles, so that I can read them offline during my commute"

• Clear user, clear need, clear value

More Good Examples

E-commerce:

As a returning customer, I want to reorder my previous purchases with one click, So that I save time on routine shopping

Banking app:

As a freelancer, I want to categorize my transactions, So that I can track business expenses for taxes

Social media:

As a content creator, I want to schedule posts in advance, So that I can maintain consistent presence while traveling

Define acceptance criteria

Acceptance criteria define the outcomes engineering and QA can check to determine whether a story is complete.

Start Simple: The Checklist

A checklist is a straightforward way to record acceptance criteria.

For our password reset story:

- User receives email within 2 minutes
- Link in email works for 24 hours  
- User can set a new password
- Old password stops working
- User gets confirmation

Check each criterion when reviewing whether the story meets its requirements.

What Makes Good Criteria?

Ask yourself:

• Can someone test this? (Not "system should be fast" but "page loads in 2 seconds")
• Is it clear? (Your QA tester should understand immediately)
• Does it focus on WHAT happens, not HOW? (Results, not methods)

Review story quality

The INVEST criteria² provide six checks for story quality:

Check whether a story is ready

1. Independent: Can it be planned separately from other stories? Identify dependencies that could affect delivery.
2. Negotiable: Can the team discuss and adjust the details?
3. Valuable: Does it provide value to a user or customer?
4. Estimable: Does the team understand it well enough to estimate the work?
5. Small: Can it fit within the team’s planning period? Split it if needed.
6. Testable: Can the team verify the acceptance criteria?

Red Flag Example

Story: "Implement backend infrastructure"

What's wrong?

• No user mentioned
• No value stated
• Scope is unclear
• No testable outcome is specified

A clearer story: "As a developer, I want a user authentication service, so that I can secure user accounts without building from scratch"

Prioritizing Your Stories

After writing multiple user stories, decide which to build first by using a prioritization framework to evaluate each story's value against its effort.

Estimating Story Size

Teams often estimate story size using "story points", relative measures of effort.

Illustrative estimates: These sizes depend on the team and its existing system.

• Base story (3 points): "User can reset password via email"
• Simpler story (1-2 points): "User can login with Google"
• Complex story (8 points): "User can enable two-factor authentication"
• Too big (20+ points): "User can export all their data" (needs splitting)

Story Splitting Patterns

When stories are too big, split them by:

• User steps in a workflow
• Different user types
• Business rules
• Data types

Common mistakes

Mistake 1: Writing for the System, Not Users

Wrong: "As the database, I want to be optimized" Right: "As a user, I want faster search results, so that I don't abandon my session"

Mistake 2: a story that is too large

Wrong: "As a user, I want a complete messaging system"

Right: Break it down:

• "As a user, I want to send text messages"
• "As a user, I want to see message history"
• "As a user, I want to know when messages are read"

Mistake 3: Telling Developers How to Code

Wrong: "As a user, I want a dropdown with 5 sorting options using React Select" Right: "As a shopper, I want to sort products by price, so that I can find deals quickly"

Mistake 4: Forgetting the "So That" (No Value)

Wrong: "As an admin, I want to see logs" Right: "As an admin, I want to see error logs, so that I can help customers faster"

Draft a story

Story template

Use this template:

As a ________________
I want ________________
So that ________________

Done when:
- ________________
- ________________
- ________________

Check the focus of your draft

These phrases can help you describe the user need and value:

• "The user needs..."
• "This helps them..."
• "They can verify by..."
• "The value is..."

Check whether these phrases prescribe a solution before explaining the need:

• "The system should..."
• "Use this technology..."
• "Put a button here..."
• "The database needs..."

If they do, clarify what the user needs before specifying the solution.

Copy These Prompts

Converting Requirements to Stories:

Convert this requirement into user stories: [paste requirement]
- Identify the user personas involved
- Break into small, independent stories
- Use the "As a... I want... So that..." format
- Include 3-5 acceptance criteria for each story

Writing Acceptance Criteria:

Write acceptance criteria for this user story: [paste story]
- Use Given-When-Then format
- Include happy path and edge cases
- Make each criterion testable
- Focus on behavior, not implementation

Story Splitting:

This user story is too large for one sprint: [paste story]
Split it into smaller stories using these patterns:
- By user steps/workflow
- By business rules
- By data types
- Show how the stories connect but remain independent

Estimating Story Points:

Estimate story points for these user stories:
Base reference: [paste a 3-point story]
Stories to estimate: [paste stories]
- Compare complexity relative to base
- Consider effort, uncertainty, and dependencies
- Suggest if any stories need splitting

Templates and Examples

User Story Template:

STORY-ID: [JIRA/Azure ID]
Title: [Short descriptive title]

As a [specific user persona]
I want [specific functionality]
So that [business/user value]

Acceptance Criteria:
1. [Specific testable criterion]
2. [Specific testable criterion]
3. [Specific testable criterion]

Notes:
- [Any additional context]
- [Links to designs/mocks]
- [Dependencies or risks]

Illustrative project example:

STORY-101: Save favorite restaurants

As a regular customer
I want to save my favorite restaurants
So that I can quickly reorder from places I love

Acceptance Criteria:
- Heart icon appears on restaurant cards
- Clicking heart adds/removes from favorites
- Favorites appear in a dedicated "Favorites" section
- Maximum of 50 favorites allowed
- Favorites sync across devices
- Unfavoriting removes it immediately

Notes:
- Design mockup: [link to Figma]
- Coordinate with backend team on sync logic
- Consider offline behavior as follow-up story

Working with your team

Who Writes What

• You (PM): The story and acceptance criteria
• Designer: Visual specs (linked to your story)
• Developer: Technical approach (their choice)
• QA: Test cases (based on your criteria)

Your First Week Writing Stories

Day 1-2: Write stories for features you personally use Day 3-4: Share with a developer friend for feedback Day 5: Write stories for your actual product Weekend: Review which stories were clear vs confusing

What to review with your team

• Clear user focus
• Understandable value
• Testable outcomes
• Willingness to clarify

Practice with your team

Write a story for an app you use, then share it with a developer for feedback. As you write more stories, track which ones need clarification and use that feedback to improve the next set.