Tuesday, December 5, 2023

Subscribe to the RSS Feed

Use cases – User Stories: so precious but not the same !

Posted by jc-Qualitystreet on 2009/01/23

Use cases and user stories are two popular ways to capture functional requirements. They’re both goal-oriented (a very good thing), can be discovered during user / customers workshops, can be easily combined with UX activities, and are used in Agile contexts.

Use cases and user Stories look similar; actually, they’re different. Here is the list of 14 major differences I’ve observed:

  1. A user story is a brief description of functionality as viewed by the user (Role → Goal); it doesn’t model the interaction between the actor and the system, what the use case does. A user story is not a sequence of actions.
  2. A user story is short and consist in one or two sentences written in the language of the user (example: As a recruiter, I can submit job vacancies). A role and a goal, then it is discussed. A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.
  3. A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension
  4. User stories are used for planning. They play a major role in project estimation and planning (via story points and velocity). Use cases are not used for planning, even if you can use « use cases points » technique to estimate project size.
  5. User stories emerge faster than use cases; use cases require more time for analysis and writing
  6. User stories are more readable than use cases; use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template
  7. User stories are easier to maintain than a 150 pages Use cases Document
  8. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details. Use case is a textual model (associated with diagrams): every thing is written !
  9. User stories are in theory written on cards (remember the 3 C rule: Card, Conversation, Confirmation): they’re not intended to be archived unlike use cases.
  10. A user story must be implemented and tested in one iteration; a specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …
  11. User stories can be more easily written by a user or customer; most of the time use cases are written by user proxies (BA, Consultants …)
  12. User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation
  13. Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !
  14. Finally, Use cases and user stories were originally associated with two different methodologies (Unified Process vs eXtreme Programming). But both can be used with agile methods and unified process !

My preference:

I have almost a ten years experience with use cases. Alistair Cockburn’s book « Writting effective use cases » used to be my bible for years… but now, my preference tends to go to user stories model. And this is usually my recommendation to Agile Teams.

Why ?

  • User stories focus on what is really important
  • User stories are more appropriate for collaboration
  • User stories can perfectly be combined with UX activities (Personas, Storyboard, Wireframes):
    User stories + UX artifacts = Just enough

  • Jeff said,

    Thanks, very good article. Check out :

  • Jonathan Babcock » Blog Archive » Use Cases or User Stories? Read Up! said,

    […] UX points out “14 major differences” between use cases and user […]

  • gabriel solomon said,

    Congrats on a very well & structured article.
    I personally like users stories because it enables the client to get involved in the development of the project more, because the dev team will speak his language instead of a long specs document filled with terminology that he doesnt understand

  • Yvonne said,

    Thank you! I have had this discussion with developers, managers and interaction designers a few times. Your article supports my opinion exactly.

  • enolf said,

    « Use case is (too much) detailed ». Too much… What brings people to describe things that aren’t needed?

    « User stories are easier to maintain than a 150 pages Use cases Document ». Why would anyone need to write 150 pages?

    Sorry, but telling people they should do things the easy and simple way instead of the hard and complex way doesn’t add any valuable knowledge. It’s just preaching to the choir.

  • Historias de Usuario vs. Casos de Uso said,

    […] prácticas’ a la hora de crear historias de usuario en particular, me encontré con el estupendo post de Jean Claude Grosjean sobre las diferencias existentes entre un caso de uso y una historia de […]

  • Didia_Sc said,

    Using only US you will run into a problem of trace of requirements at their change in a course of working out of the big project (more than 3000 h/hours).

    Yes, you tell that the command is the keeper of knowledge but that will be if the employee in holiday, was ill or has left. Even worse if was ill and in holiday and has left 🙂

    What then to do?
    Who will recollect all nuances?


  • Brenda said,

    I completely disagree with the op’s conclusions. I’ve learned over and over that US’s are appropriate from the end user’s perspective, but sorely lacking from the developer’s perspective. It has been my experience that US’s require the developer to constantly go back to PM and ask questions whose answers would have been covered in a good UC… and when dealing with more junior developers, that usually results in discovering a big miss during testing.

  • David Draper said,

    Interesting perspective. Let me add a couple of (IMO) key differences:
    – User Stories are a work scheduling technique – we split user stories for the convenience of teams and let the team design a way for the user to achieve their goal.

    – Use Cases express the design of a system – a use case describes an interaction between actor and some system.

    Since they solve different problems they can be combined. I’ve worked with teams for whom the use-case was considered a valuable artefact describing the current state of the system. In this context we used user stories to schedule work; the work included designing the interactions and documenting as a use case.

  • jc-Qualitystreet said,

    @David: thanks for tour feedback. I also have teams that combine UC and US. It’s an option due to différent Level of granularity and, as you said, different purpose.
    But, i think it adds a degree of complexity…

home | top