.svg){kind=small}
User stories and use cases both help teams understand what people need from a solution, but they do it at different levels of detail. A user story is normally a short expression of a need or outcome that supports conversation and iterative delivery. A use case describes the interactions and alternative paths through which an actor tries to achieve a goal with a solution.
They are not competing techniques. A Business Analyst can use either or both depending on the complexity of the problem, the delivery approach and how much behavioural detail the team needs.
User stories vs use cases at a glance
| User story | Use case |
|---|---|
| Short statement of need or value | Structured description of interactions to achieve a goal |
| Common in Agile backlogs | Common in detailed requirements and solution analysis |
| Designed to prompt conversation | Designed to explore behaviour and paths |
| Often supplemented by acceptance criteria | Includes main and alternative flows |
| Usually relatively small in scope | Can describe a broader user goal |
| Does not attempt to document every interaction | Can capture exceptions and variations explicitly |
What is a user story?
A user story is a concise description of something a user or stakeholder needs.
A familiar format is:
As a [type of user], I want [capability], so that [benefit].
For example:
As a customer, I want to save an incomplete course booking so that I can return and finish it later.
The sentence is intentionally brief. It is not meant to contain the entire requirement.
The story acts as a reminder to discuss the need, understand the context and agree the conditions under which it will be considered complete.
What is a use case?
A use case describes how an actor interacts with a solution to achieve a particular goal.
IIBA describes use cases as a technique for showing interactions between a primary actor, the solution and supporting actors, including different paths towards the actor's goal.
A use case commonly includes:
- the goal
- the primary actor
- trigger
- preconditions
- a main or basic flow
- alternative flows
- exception flows
- postconditions or outcomes
A use case therefore explores behaviour in greater depth than a short user story.
A simple user story example
Consider an expense system.
As an employee, I want to submit an expense claim online so that I can be reimbursed without sending paper forms.
Useful acceptance criteria might include:
- the employee can add one or more expense items
- each item requires a date, category and amount
- receipts can be attached
- the employee can save a draft
- the employee can submit a completed claim
- the system confirms successful submission
The story states the need. The acceptance criteria clarify important conditions.
The same requirement as a use case
A use case might be titled Submit Expense Claim.
Primary actor: Employee
Trigger: Employee chooses to create a new expense claim.
Main flow:
- The employee starts a new claim.
- The system displays the claim form.
- The employee enters expense details.
- The employee attaches supporting receipts.
- The employee submits the claim.
- The system validates the information.
- The system records the claim.
- The system confirms submission.
Alternative flows could describe saving a draft, correcting incomplete information or handling an invalid receipt file.
The use case makes the interaction sequence much more explicit.
Are user stories requirements?
A user story can represent a requirement or stakeholder need, but the sentence alone is rarely a complete specification.
Good Agile teams rely on conversation, examples, acceptance criteria, models and other supporting information rather than expecting the user story card to contain everything anyone could ever need to know.
This is sometimes expressed through the idea of the “3 Cs”:
- Card: a concise reminder of the need
- Conversation: collaborative exploration of what it means
- Confirmation: agreement on how the team will know the need has been met
Are use cases requirements?
Use cases are a technique for analysing and representing behavioural requirements. They focus on the interactions needed to achieve a user goal.
They do not describe every type of requirement. A use case may need to be supplemented with:
- business rules
- data requirements
- non-functional requirements
- interface requirements
- process models
- prototypes
For example, the use case may explain how someone logs in, but security requirements may separately define authentication controls, audit logging and session behaviour.
What are acceptance criteria?
Acceptance criteria define conditions that help determine whether a story has been implemented acceptably.
They can describe:
- business rules
- expected outcomes
- examples
- valid and invalid scenarios
- boundaries
- important quality conditions
Acceptance criteria should make the story clearer without turning every backlog item into an enormous document.
User story vs acceptance criteria
The user story expresses the need and value. Acceptance criteria add specific conditions for acceptance.
For example:
Story: As a learner, I want to filter courses by subject so that I can find relevant training more quickly.
Acceptance criteria:
- the user can select one or more subject categories
- the results update to show matching courses
- the user can clear all selected filters
- a suitable empty-state message appears when no courses match
Use case vs use case diagram
A use case diagram is not the same as the written use case.
The diagram provides a high-level visual view of:
- actors
- use cases
- the system boundary
- relationships between them
The written use case then describes the interaction paths in detail.
IIBA notes that use case diagrams help show solution scope by illustrating which actors interact with which use cases.
Which is more detailed?
A use case is normally more detailed than a user story.
That does not automatically make it better.
Too much detail too early can create waste if requirements are likely to change. Too little detail can leave developers, testers and stakeholders with different interpretations of complex behaviour.
The right amount of analysis depends on risk and complexity.
When are user stories most useful?
User stories work particularly well when:
- the team uses an Agile or iterative delivery approach
- needs can be broken into relatively small increments
- users and subject-matter experts are available for ongoing conversation
- details can be refined close to implementation
- the team wants to prioritise work in a backlog
They are especially useful for keeping attention on user value rather than writing features solely from the system's perspective.
When are use cases most useful?
Use cases can be particularly valuable when:
- user-system interactions are complex
- many alternative or exception paths exist
- the sequence of behaviour matters
- different actors participate in one goal
- developers and testers need a shared behavioural model
- the solution must handle many error or boundary scenarios
IIBA's use-case guidance highlights their usefulness for discovering features, functions, interface needs and alternative interaction paths.
Can you use both together?
Yes. They can complement each other.
A team might keep a concise user story in the backlog and create a use case or scenario model where one area of behaviour is too complex to understand through a short statement and acceptance criteria alone.
For example, an apparently simple story such as “As an administrator, I want to cancel a booking” may hide several questions:
- Has the course already started?
- Has payment been made?
- Is a cancellation fee due?
- Should another delegate be offered the place?
- Which emails are sent?
- What happens to an invoice?
- Can a cancellation be reversed?
A more detailed use case can help explore those paths.
User stories and requirements gathering
A user story should emerge from understanding a real stakeholder need rather than being invented by the delivery team in isolation.
Requirements elicitation techniques such as interviews, workshops, observation and process modelling help uncover the context behind backlog items.
See What Is Requirements Gathering?.
Use cases and requirements gathering
Writing a use case is itself an analytical process. Walking through the main path and asking “What could happen differently here?” often reveals requirements that were previously hidden.
Useful questions include:
- What starts this interaction?
- What must already be true?
- What information does the actor provide?
- What does the system validate?
- What if validation fails?
- What other systems or actors participate?
- What defines successful completion?
User stories and non-functional requirements
User stories often focus on functional outcomes, so teams need a deliberate way to capture cross-cutting quality requirements such as:
- performance
- security
- accessibility
- availability
- privacy
Some may appear in acceptance criteria, while others apply across many stories or the whole product.
See Functional vs Non-Functional Requirements.
Use cases and non-functional requirements
Use cases also focus primarily on behaviour. A detailed interaction flow does not automatically tell you how fast, secure, accessible or reliable the solution must be.
Use cases therefore need to sit within the wider requirements model rather than become the only documentation technique.
What makes a good user story?
Good stories are:
- centred on a genuine user or stakeholder need
- clear enough to support conversation
- small enough to be useful for planning and delivery
- valuable
- testable through appropriate acceptance criteria
A commonly used reminder is INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable.
Common user story mistakes
- Using the template mechanically. The sentence is grammatically correct but expresses no meaningful user value.
- Treating the story as the whole specification. Important rules and examples are never discussed.
- Writing technical tasks as fake user needs.
- Creating stories that are far too large.
- Using vague acceptance criteria.
- Never speaking to the actual users.
Common use case mistakes
- Writing interface design rather than user-system interaction.
- Ignoring alternative and exception flows.
- Creating enormous use cases that try to model an entire business process.
- Using technical implementation language too early.
- Documenting behaviour nobody has validated with stakeholders.
- Assuming use cases capture non-functional requirements automatically.
User stories vs process models
A process model describes how work flows across activities, roles and decisions. A user story describes a particular need. They answer different questions.
A BPMN model might reveal that a manager approval occurs after an expense claim exceeds a threshold. That process step can lead to several user stories or use cases for the system supporting the process.
See What Is BPMN?.
User stories vs tasks
A user story describes value or capability from a user or stakeholder perspective. A task describes work the delivery team needs to perform.
One story may require several technical tasks such as:
- create a database field
- build an API endpoint
- update the user interface
- write automated tests
Those tasks support delivery of the story but are not themselves user stories.
How should a Business Analyst choose?
Ask:
- How complex is the interaction?
- How much uncertainty exists?
- Are stakeholders available for ongoing conversation?
- How many alternative and exception paths matter?
- What level of detail do developers and testers need?
- What documentation standards does the organisation require?
- Would another model communicate the requirement more clearly?
Use the lightest technique that gives the team enough shared understanding.
Frequently asked questions
Are user stories only used in Scrum?
No. User stories are strongly associated with Agile delivery but are not owned by Scrum and can be used in other iterative approaches.
Do use cases have to use UML?
No. UML provides a standard notation for use case diagrams, but the written behavioural description is the most important part of the technique.
Can one use case contain several user stories?
Yes. A broader use case goal may be delivered through several smaller backlog stories.
Do user stories replace requirements documents?
Not automatically. The appropriate documentation depends on risk, regulation, complexity, delivery method and stakeholder needs. User stories may be one part of a wider requirements approach.
Which is better for testers?
Both can be useful. Acceptance criteria provide clear conditions for individual stories, while use-case flows can help testers identify main, alternative and exception scenarios. The better technique depends on the complexity being tested.
Can a Business Analyst write user stories?
Yes. Business Analysts frequently help discover, refine and document user stories in collaboration with Product Owners, stakeholders and delivery teams.
Develop your requirements skills with ExperTrain
ExperTrain offers instructor-led Business Analysis training for professionals who need to elicit, analyse, model and document requirements effectively.
The Business Analysis: Requirements Development, Documentation and Management course develops practical requirements skills across elicitation, modelling, quality, traceability and lifecycle management.
For a broader foundation, consider the EXIN BCS Foundation Certificate in Business Analysis.
You can also explore the Business Analysis Glossary and related guides on stakeholder analysis, requirements gathering and functional vs non-functional requirements.
Further reading
Found this article useful? Add ExperTrain as a Preferred Source on Google to help surface more of our training guides, articles and learning resources.
.png){kind=small}
