3

I'm not certain I understand what differentiates a user story from a use case. It seems like a very fine line to me. What is a use case and how does it differ from a user story?

Improve this question

3 Answers 3

Reset to default
6

The terms are often conflated today, but for the discerning:

Use case refers more commonly to the procedural steps a user takes to get something done:

Example: Knead the flour, add some salt, place in oven, wait 30 minutes.

User story attempts to capture the experience narrative of the user. This includes the procedural steps in a use case, but also the user's goals, motivation, incentives, and sometimes emotional experience.

Example: User is a baker, and needs to bake bread quickly and consistently 
every morning at 5am.  She is often tired and it's easy to make 
mistakes at that hour. The user bakes bread by 
[insert procedural steps here].

While there are reasonably formal definitions of each within specific contexts (for example, in UML a use case can be formally modeled, and user stories are a formal component of the Agile programming process), I don't think there is broad consistency of use, so I've tried to use a vernacular definition above.

Notably, the Wikipedia entries for Use Case and User Story use context- and usage- qualifiers to define the terms, because of the ambiguity.

Improve this answer
2
  • 2
    +1 for motivation and goals of the user. Each story may have incentive for the user in a different way, and this allows you to capture them in context. As you show, the actor of the use case may be a baker, but the most important implications for the story may not be as apparent.
    – John Deters
    Mar 15, 2015 at 21:12
  • Is there a time where you would opt to use one over the other?
    – Erika Randall
    Mar 18, 2015 at 15:55
2

The terms user story and use case are not terms that come from HCI. "Use case" come from software engineering. "User story" comes from the Agile method of software engineering.

From About Face: "Use cases...are a technique based on exhaustive descriptions of functional requirements of the system, often of a transactional nature, focusing on low-level user action and accompanying system response... In our experience, the biggest shortcoming of traditional use cases as a basis for interaction design is their tendency to treat all possible user interactions as equally likely and important. This is indicative of their origin in software engineering rather than interaction design." A use case takes an "actor" and a "goal", then list the "tasks" they do to achieve the goal. In software engineering, an "actor" does not need to be a person; it can be one part of a system interacting with another part of a system. This is useful to help scaffold or compartmentalize the code.

I believe that a user story is essentially a use case, but much, much shorter and more precise. Define the actor, the goal, and the outcome. I should not be more than a single Post-It can handle.

User story for agile make sense, because the dev cycle is shorter and faster; instead of making all of the decision now, you make what you can and then revisit your decisions in the next cycle. On the other hand, making a traditional use case takes more time and effort, but you have a greater understanding of your functionality.

Improve this answer
2
  • This is consistent with what I've encountered. User stories should be short and persona/role focused; use cases are more detailed and focused on procedure. Beyond those, there's a scenario that sort of marries the two and should be well researched.
    – plainclothes
    Jan 5, 2016 at 19:28
  • @plainclothes Scenario is a term in HCI and, yes, it should be based on research. "User stories should be short and persona/role focused". I'd argue that a user story is not necessarily based on a persona as defined in UX, that is based on interviews and ethnographic data, and probably won't be given a shortened dev schedule. Instead, yes, more role or actor focused, as defined in programming. Aside from scenarios, all of these tools are traditional ways of defining software requirements, but may not be the best way to go about determining how to present functionality to actual end users.
    – user70848
    Jan 5, 2016 at 20:32
0

For those tl;dr peoples, a shortened answer would be:

Use Case = An instance where a user would use a feature.

User Story = A complete example from the initial point of contact until task completion where a set of features would be used.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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