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.
3 down vote
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 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.
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:
I am a Customer and I want to pay my account balance online –a pretty high-level view
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)
http://wiki.c2.com/?UserStoryAndUseCaseComparison
