Is there an exact, but simple and understandable defintion of the distinction between "use case", "User Story" and "Usage Scenario"?

there are quite a bunch of explanation, but right now, I see no one that explains the differences in a single sentence, or two...

(e.g. http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison very long and hard to get, full of discussion)

  • 3
    Thank you for your question. For some reason, people who come up with methodologies are never accurate deliberately (I assume)so that their thoughts are never accused to be not applicable to certain situation. This is dragging the entire industry back, where each of us has to create an adaption that works before using the methodology. I hope the community stands against this behavior. Sometimes, you pick 2 books and they define things differently - Science does not work this way. – NoChance Oct 10 '11 at 10:03
  • I suggest you check the Wikipedia definition of each of your terms. It may help you understand better what the terms mean. Also note that the terms come from different concepts. For example, user story is an Agile tool/technique and Use Case is an OOA tool/technique. – NoChance Jan 5 '12 at 15:04

10 Answers 10


A User Story is a more informal, friendlier and smaller version of a Use Case, minus the UML diagram; it is typically used in iterative scenarios.

A Usage Scenario is a Use Case drawn out into a step-by-step procedure, sometimes accompanied by a flowchart.


To me, the biggest differences between a User Story and a Use Case are:

  • A user story is a lightweight document that can be written on a card (In order to , as a , I want ). A User Story doesn't capture all the details, it's an informal support for the discussion.
  • A use case is an heavyweight document that needs a word document. It describes a "Normal Flow" of steps and/or actions and "Alternative Flows" which are detailed. A Use Case captures all the details, it's a formal specification.

According to Scott W. Ambler on Usage Scenarios, these artifacts look like a Use Case's flow:

A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction. Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they’re performed.

Honestly, the differences with a Use Case's flow is not crystal clear, even after reading this paragraph (the last sentence being maybe the most important):

As you can imagine, there are several differences between use cases and scenarios. First, a use case typically refers to generic actors, such as Customer, whereas scenarios typically refer to examples of the actors such as John Smith and Sally Jones. There’s nothing stopping you from writing a generic scenario, but it’s usually better to personalize the scenarios to increase their understandability. Second, usage scenarios describe a single path of logic whereas use cases typically describe several paths (the basic course plus any appropriate alternate paths). Third, in UP-based processes use cases are often retained as official documentation whereas scenarios are often discarded after they’re no longer needed.

I may be wrong, but Usage Scenario really sounds like Use Case flow but rebranded with an Agile touch.

  • I think personalizing the scenarios is harmful (at least as I understand it). You say "it’s usually better to personalize the scenarios" - But what if Sally Jones left the company or changed position - What value would the scenario have? – NoChance Oct 10 '11 at 9:40
  • Personalizing does not mean designing for a real person. It could for for a real person, but it could also be for a fictive person, as with the "Personas" tool. The arguments for using specific users (real or fictive), with a personality, is that the scenarios become more "real". It is easier for the programmer to understand the user when understanding the personality of that user, instead of trying to understand an abstract imprecise user. Please let me know if I am wrong, or if I misunderstood your comment. – Mads Skjern Sep 21 '15 at 15:28
  • Regarding A use case is an heavyweight document that needs a word document.. Martin Fowler thinks that Use case are at their best when they are short and readable. You should not be spending weeks, let alone months, generating use case documents before you begin development. – wha7ever - Reinstate Monica Jun 29 '18 at 18:37

There isn't an exact definition of any of this stuff. It all varies a little bit (or a lot) from company to company and from system to system.

Your best bet is to find an example already in place for your current project and follow it.

If you are creating a new system, you can find definitions of different types of use cases for whatever system you prefer--Just pick the pattern that seems to communicate your intentions best.

Don't get hung up on names.

  • 1
    > Don't get hung up on names. Don't worry, I won't! :) on the other hand, it's a quite desireable goal when in a team all members mean and understand the meaning of a word in a similar manner – Henning Sep 30 '09 at 15:55
  • 1
    I totally agree-but at a team level. I just find that a "Global" level, I've never seen two people define "Use Case" the same way. – Bill K Sep 30 '09 at 17:23
  • Not same, but on similar tendencies... and it's at least these tendencies I wanted to know and understand – Henning Oct 1 '09 at 10:15

A user story is always informal and describe a user's need. A use case can be either formal or informal, and describes system behavior.

It is possible to have "tech" user stories, the same is not true for use cases.

Once done, the user story is typically discarded. Use cases may be maintained during the product life cycle.

The scope is also different. User stories are typically smaller in scope, and consequently a use case comprises several user stories. A changed requirement for an existing system is described in a new user story, or an updated version of the use case.

The similarity between user stories and uses cases is that both of them are used for planning and scheduling.


A User Story when decomposed to tasks that are individually assignable to developers may or may not be more granular and constrained in scope than a Use Case Scenario. A User Story is about the need of the User -- a Goal or Outcome from their using the System.

Examples of User Stories are:

  1. I am a Customer and I want to pay my account balance online --a pretty high-level view
  2. I am a Customer and I want to update the expiration year on my stored credit information -- a pretty granular view.

At the highest level of abstraction a Use Case sounds very similar -- Customer Updates Card Expiration Year -- but here its a statement of function rather than goal.

As the granularity of the Use Case scenarios are defined they become more about function and procedure.

The Post-condition of a Use Case Main Scenario should be the same outcome as that stated in the User Story -- Customer's Credit Card Expiration Year is Updated.

Use Case Scenarios describe step-by-step either in text or process flow chart (not necessarily UML or BPM - I use a standard cross-functional flow diagram for clarity and ease of use by untrained consumers of the use case.

The bottomline is that User Stories describe Needs and Outcomes (What the System Needs to Deliver) whereas Use Cases describe interactions between Actors required to meet the goal - AND what can go wrong (Extension, Alternate or Error Scenarios) (how the user interacting with the System achieves that outcome)

For a discussionin depth on this topic I suggest reading http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison on Alistair Cockburn's website. Since he's a signatory of the Agile Manifesto, the person who coined User Stories and has been considered a Use Case expert for the last couple of decades I think he's an excellent source for more info.

  • 2
    This is just a wall of text; can you edit this for readability. – Martijn Pieters Dec 8 '13 at 21:01

Quick temporary note: This post needs improvements to better answer the question, such as 1) additional details should be included from references 2) some citations maybe 3) overall correctness of English 4) overall quality of narrative 5) etc. I'll be back to it. Feel free to improve it yourself.

Taking a look at their templates can give valuable insight into the differences between these terms.

Use case

There are multiple templates for use cases. I found 3 after a quick search: 1, 2, 3. Some points they (sometimes vaguely) have in common are:

  1. Name of use case / title
  2. Description - some short text describing the scope.
  3. Actor(s) / Primary actor - person(s) who interact with this particular use case.
  4. Precondition - anything that this use case can assume to be true prior to beginning it's life cycle.
  5. Success scenario - a sequence of step describing correct flow of events that take place.
  6. Extensions - flow of application when it deviates from success scenario's flow:

    1. Alternate flows - other options of correct flow
    2. Exception flows - flow of events for when things go wrong
  7. Success guarantee (aka. Post condition) - state of application after everything is done

Some additional points that can be included are Level, Minimal Guarantees, Trigger, etc.

Above is what's called fully dressed use case. You can simplify use case creation by using a casual use case by using only the most vital points, for example:

  1. Title
  2. Actor(s)
  3. Sequence of events

Use cases were created and popularized by Ivar Jacobson in late 80s early 90s. Later other people also contributed to his work (one of such people is Alistair Cockburn who is author of Writing Effective Use Cases). To paraphrase Martin Fowler use cases can make use of text and UML diagrams, but their greatest value lies in the text of it. They are best when they are not big and easy to read.

User story (aka. Feature)

User story - a small story that describes a particular feature. There is a common pattern of how to write a user story, which is:

As a particular type of a user
I want to do something
so that some reason.

In addition, user story can have acceptance criterias.

As you can see this template is much smaller than that of use case. User stories are commonly associated with scrum/agile/xp region of software development. They are meant to be written on small regions of surface, such as post-it notes, and/or on scrum boards. There, they are (usually) given point values which approximate how much effort needs to be invested into that user story ref.

Bill Wake developed INVEST mnemonic to describe what qualities a good user story should have, and I will borrow Martin Fowler's short summary of that from his website:

Independent: the stories can be delivered in any order
Negotiable: the details of what's in the story are co-created by the programmers and customer during development.
Valuable: the functionality is seen as valuable by the customers or users of the software.
Estimable: the programmers can come up with a reasonable estimate for building the story
Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration.
Testable: you should be able to write tests to verify the software for this story works correctly.

Usage scenario

Usage scenario follow the GWT pattern which stands for Given-When-Then, like so:

Scenario: title
Given: a particular fact
And: another particular fact (may be optional)
When: some event happens
Then: some other event happens

Usage scenarios are associated with Behavior-Driven Development. It sounds very similar to a test. Martin Fowler in his blog post gives some history and reasoning behind usage scenarios. Here is the important part:

The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test.
The when section is that behavior that you're specifying.
Finally the then section describes the changes you expect due to the specified behavior.

Usage scenarios can be used for writing test for your application. To quote the last paragraph of Martin's post:

Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.

References for farther study:

Wikipedia pages for use case, user story, usage scenario
Martin Fowler's blogs on use case, user story, usage scenario


I am not familiar with User Story, but when I looked into this several years ago:

A Use Case is a major task.
User Scenarios are the various ways that task can play out. So, Every Use Case has one or more scenarios. The Use Case is the abstract, the User Scenarios are a catalog of all possible instances of that abstract task.

Use Case A: User authenticates with id and password.

1. ID is recognized, password is correct. ("sunny day" scenario)
2. ID is recognized, password is incorrect.
3. ID is recognized, password is incorrect for third time.
4. ID is not recognized.

I have always thought of use cases as a way of defining requirements in a narrative way for the client in their terms. w/r/t the above, if the client says "But what if they try to log in in between midnight and one when the system is down?", we have discovered another scenario for the authentication task, and some additional requirements.


A user story is from a customer's point of view, sometime it's incorrect or incomplete. It may have no consideration on performance, on error handling, or nothing on the backend.

A use case is from dev's point of view. It's accurate and complete. It should answer all the requirements from customers.


"Use case" and "user story" are the same in the sense that they represent "requirements" of customer.

Use case is the way the system is used in each case, normally represented as an interaction between actor and system or between systems.

User story is the starting point in the journey to create a computer aided tool that will enable end-user to get something done, and normally begins with a simple sentence using who, what, why ("As a user closing the application, I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work."). That user story then needs to be cultivated into a use case that developers employ to build an application, and testers to conduct testing.

From the perspective of a QA Tester, they're not testing "user stories", but rather "use cases", meaning they're testing software functionalities.

  • 1
    While correct, this doesn't add anything to the answers that have been in place for 4 years already. – Adam Zuckerman Nov 4 '14 at 21:41

The purpose of the Usage Scenario is to capture the essence of the user interaction with your system towards achieving a goal, without diving into the details of the system actions or the actual design. The focus is on the User, not the system.

... Use Case also includes statements about what the system will do, whereas the Usage Scenario will avoid this discussion.

You haven’t yet determined how you’re going to implement it.

From the product-arts site.

  • This does not add anything above and beyond the accepted answer which was posted more than seven years ago. Furthermore, quoting sources is good, but it would be better to explain it in your own words: what does the text mean to you? – user22815 Jan 28 '17 at 19:20
  • Just to be clear: there is nothing wrong with replying to old questions. Stack Exchange does not have an anti-necromancy policy. But if you are late to the discussion, please be sure to add new information, possibly information that was not available seven years ago. – user22815 Jan 28 '17 at 19:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.