A good user story is the foundation of successful sprint planning. It captures who wants something, what they want, and why it matters—all in a format your team can estimate, discuss, and deliver.
Bad user stories lead to confusion, wildly different estimates, and features that miss the mark. Good user stories create shared understanding and make planning poker actually work.
Here's everything you need to know.
The User Story Template
Real Example:
What Makes a Good User Story
User-Focused
Written from the perspective of the person who will use the feature, not the developer building it.
Conversational
Simple language that anyone on the team can understand. Avoid technical jargon.
Specific but Flexible
Clear enough to estimate, but leaves room for technical implementation decisions.
Outcome-Oriented
Describes the desired result, not the technical solution or implementation details.
Sized Right
Can be completed in one sprint. If it takes weeks, break it into smaller stories.
Vertically Sliced
Includes all layers (UI, logic, data) needed to deliver working functionality.
The INVEST Criteria
A good user story follows the INVEST principles. Use this as your quality checklist.
Independent
Stories should be self-contained and not dependent on other stories when possible.
Each story can be developed and delivered separately without waiting for others.
Negotiable
Details can be discussed and refined. Stories are not rigid contracts.
The implementation approach can be adjusted based on technical constraints.
Valuable
Every story must deliver clear value to users or stakeholders.
Each story answers "Why does this matter to the user?"
Estimable
The team must be able to estimate the size and complexity.
Stories have enough detail for the team to assign story points.
Small
Stories should be completable within a single sprint.
If a story takes more than 13 points, split it into smaller stories.
Testable
Clear criteria exist to verify when the story is complete.
Acceptance criteria define what "done" means for this story.
Good vs Bad User Stories
User Story Structure
Add login functionality
No user perspective, no value statement, too vague
As a returning customer, I want to log in with my email and password, so that I can access my order history and saved preferences.
Clear user role, specific action, explicit value
Scope & Size
As a user, I want a complete e-commerce checkout system, so that I can purchase products.
Too large, contains multiple features, not estimable
As a customer, I want to add items to a shopping cart, so that I can review my selections before purchasing.
Single focused feature, completable in one sprint
Value Clarity
As a developer, I want to refactor the authentication service, so that the code is cleaner.
No user value, technical task disguised as story
As a user, I want the login process to complete in under 2 seconds, so that I can access my account quickly.
User-focused outcome, measurable value
Acceptance Criteria
As a user, I want to search for products.
No definition of done, missing acceptance criteria
As a shopper, I want to search for products by name, so that I can quickly find what I need. AC: ✓ Search returns results within 1 second ✓ Results show product image, name, price ✓ No results shows helpful message
Clear, testable acceptance criteria define done
Acceptance Criteria Best Practices
Acceptance criteria define what "done" means. They turn a vague story into something your team can test, estimate, and deliver with confidence.
Use Given-When-Then Format
Structure criteria as scenarios to make them clear and testable.
Given I'm on the search page, When I enter "laptop" and click search, Then I see relevant laptop products within 1 second.
Make Them Testable
Each criterion should be verifiable with a yes/no answer.
✓ User receives confirmation email within 5 minutes (testable) ✗ System performs well (not testable)
Include Edge Cases
Don't just define the happy path. Consider errors and boundaries.
✓ Empty search shows "No results found" ✓ Special characters are handled safely ✓ Results are limited to 50 items
Keep Them Concise
Each story should have 3-5 acceptance criteria. More means the story is too big.
If you have 10+ criteria, split into multiple stories.
A Complete User Story
- ✓All team member estimates are visible after reveal
- ✓Average and median are calculated and displayed
- ✓Results can be exported to CSV for record keeping
- ✓Team can optionally re-estimate if consensus isn't reached
How User Stories Connect to Planning Poker
Well-written user stories make planning poker effective. Poorly written stories lead to confusion, wildly different estimates, and wasted time.
Before Planning Poker
- →Stories are refined and follow INVEST principles
- →Acceptance criteria are clear and testable
- →Team has enough context to estimate
During Planning Poker
- →Product Owner reads the story aloud
- →Team asks clarifying questions
- →Each person estimates based on story + criteria
Pro Tip
If your team can't estimate a story, it's usually because the story isn't ready. Send it back for refinement instead of forcing an estimate. Good stories lead to confident estimates.
Common Mistakes to Avoid
Technical Tasks as Stories
Fix: Focus on user value, not implementation. "Refactor database" is a task. "Load dashboard in under 2 seconds" is a story.
Epic-Sized Stories
Fix: If a story takes multiple sprints, it's an epic. Break it down into smaller, deliverable pieces.
Missing Acceptance Criteria
Fix: Without clear criteria, "done" is subjective. Always define what complete looks like.
Too Much Detail
Fix: Stories aren't specifications. Leave room for team discussion about implementation.
No User Value
Fix: Every story should answer "Why does this matter to the user?" If you can't answer that, reconsider the story.
Dependent Stories
Fix: Stories should be independent when possible. Dependencies create bottlenecks in planning and delivery.
Quick Reference Checklist
Before You Write
- □Do you know who the user is?
- □Do you know what they want?
- □Do you know why it matters?
- □Can this be done in one sprint?
After You Write
- □Does it follow the INVEST principles?
- □Are acceptance criteria clear and testable?
- □Can the team estimate it?
- □Does it deliver user value?
Ready to Estimate Your Stories?
Now that you know how to write good user stories, put them into action with planning poker. Create a free room and start estimating.
Create Free Planning Room