A use case is a detailed description of how a user (actor) interacts with a system to achieve a specific goal. It includes the main success flow (step-by-step), alternate flows (variations), exception handling (error scenarios), preconditions, and postconditions. Use cases originated in UML (Unified Modeling Language) and are more structured and detailed than user stories.

Glossary

Use Case vs User Story

Q: What is a user story?

A user story is a short, simple description of a feature from the perspective of the user. It follows the format: 'As a [type of user], I want [action] so that [benefit].' User stories are used in Agile development to capture requirements in a way that's focused on user value rather than technical implementation. They're intentionally brief — the details emerge through conversation between the product team and developers.

Q: When should I use user stories vs. use cases?

Use user stories for: agile teams, sprint planning, quick alignment on what to build and why. Use use cases for: complex system interactions, compliance documentation, QA test planning, enterprise integrations. Many teams use user stories for day-to-day development and write use cases only for complex features that involve multiple system interactions or need detailed QA coverage.

Q: Can I use both user stories and use cases?

Yes — and many teams do. A common pattern: start with a user story to capture the intent and value ('As a user, I want to export data as CSV'), then write a use case for complex features that need detailed flow documentation (main flow, error handling, edge cases). The user story captures the 'what and why,' the use case captures the 'how.'

Q: How do feature requests relate to user stories?

Feature requests from users are the raw input that gets refined into user stories. A feature request ('I wish I could export my data') becomes a user story ('As a user, I want to export data as CSV so that I can analyze it in Excel'). A voting board like Features.Vote collects the raw requests; the product team formats the top-voted ones into user stories for development.

Q: Are user stories replacing use cases?

In agile-first teams, yes — user stories have largely replaced use cases for day-to-day requirements. But use cases aren't dead. They're still valuable for complex enterprise systems, regulated industries (healthcare, finance), system integration documentation, and QA test planning. The trend is toward user stories for most work, with use cases reserved for complex scenarios.

Two ways to capture requirements — one brief and value-focused, one detailed and flow-focused. Here's when to use each, with real examples you can copy.

User Story

"What and why"

"As a product manager, I want to see feature requests ranked by votes so that I can prioritize based on user demand."

1-2 sentences
User-value focused
Invites conversation
Agile teams, sprints

Use Case

"How, step by step"

"Actor: PM. Main flow: 1) Open dashboard 2) Click voting board 3) System sorts by votes 4) PM reviews top 10..."

1-3 pages
System-behavior focused
Covers all flows and exceptions
Enterprise, QA, compliance

Side-by-Side Comparison

Aspect	User Story	Use Case
Origin	Agile / Extreme Programming (XP)	UML / Object-Oriented Analysis
Format	As a [user], I want [action] so that [benefit]	Structured document with actors, preconditions, flows, exceptions
Length	1-2 sentences	1-3 pages
Focus	User value and intent (the 'why')	System behavior and interactions (the 'how')
Detail level	Intentionally vague — invites conversation	Detailed — covers main flow, alternate flows, exceptions
Audience	Product team (PM, dev, design)	Business analysts, QA, architects
Best for	Agile sprints, backlog items, quick alignment	Complex workflows, compliance docs, system integration
Lifecycle	Created and completed within 1-2 sprints	Living document, updated as system evolves
Testing	Acceptance criteria define done	Each flow (main, alternate, exception) becomes a test case
Common in	Startups, SaaS, agile teams	Enterprise, government, regulated industries

User Story Examples

SaaS Product Manager

"As a product manager, I want to see feature requests ranked by votes so that I can prioritize the backlog based on user demand."

Acceptance Criteria

Voting board shows ideas sorted by vote count
Each idea displays total vote count
Sorting can be toggled (most voted, newest, trending)

End User

"As a user, I want to submit a feature request without creating an account so that I can share my idea quickly."

Acceptance Criteria

Feedback widget visible on every page
No login required to submit or vote
Confirmation message shown after submission

Customer Success Manager

"As a CS manager, I want to be notified when a feature requested by my accounts ships so that I can proactively inform them."

Acceptance Criteria

Email notification when status changes to 'Shipped'
Notification includes the feature name and requesting accounts
Link to the changelog entry

Use Case Example

UC: Submit Feature Request

Use Case

Actor: End User

Preconditions: User has the app open with the feedback widget visible

Main Success Flow

1.
User clicks the 'Suggest a Feature' button
2.
System displays the feature request form
3.
User enters a title and description
4.
User optionally selects a category
5.
User clicks 'Submit'
6.
System validates the input (title required, min 10 characters)
7.
System saves the feature request and assigns it 'Under Review' status
8.
System displays confirmation message with a link to the public board
9.
System checks for duplicate requests and suggests similar existing ideas

Alternate Flows

Step 3a: User searches existing ideas before submitting → system shows matching ideas → user votes on existing idea instead
Step 6a: Validation fails → system highlights errors → user corrects and resubmits

Exceptions

Network error during submission → system saves draft locally → retries when connection restored
Rate limiting triggered (>5 submissions/hour) → system shows 'please wait' message

Postconditions: Feature request visible on the public board. User can track status changes.

When to Use Each

Use User Stories when…

Your team practices Agile/Scrum
You need quick alignment on what to build
Features are small enough for 1-2 sprints
You want to focus on user value, not system behavior
Your team is co-located and can discuss details verbally

Use Use Cases when…

The feature involves complex multi-step workflows
You need documentation for compliance or auditing
QA needs detailed test scenarios from requirements
Multiple systems interact (integrations, APIs)
Stakeholders need formal documentation

Both Start With User Feedback

Whether you write user stories or use cases, the input is the same: what do users actually want? A feature voting board collects raw feature requests from users. Your team then formats the top-voted requests into whichever format fits your process — user stories for agile sprints, use cases for complex workflows.

Collect

Users submit and vote on feature requests through a voting board. Raw input, unformatted.

Format

Product team formats top-voted requests into user stories (agile) or use cases (complex features).

Build

Development team implements based on the formatted requirements. Ship and notify voters.

"The easiest way to add feature voting to your app, it almost feels like it natively belongs to your application! "

Gabriel P.,

Founder at PullNotifier

Related Resources

Feature Request Templates

Free PRD Generator

Feature Voting Guide

Agile Sprint Planning

Prioritization Frameworks

Product Owner vs PM

Frequently Asked Questions

What is a user story?

What is a use case?

When should I use user stories vs. use cases?

Can I use both user stories and use cases?

How do feature requests relate to user stories?

Are user stories replacing use cases?

Still not convinced?

Here's a full price comparison with all top competitors

Is it lacking a feature you need?

Chances are, we're already working on it. Check our roadmap

Okay, okay! Sign me up!

Start building the right features today ⚡️