User Stories vs. Use Cases

We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of use cases. What are they different and what are they the same?

Use cases, usage case scenarios and user stories document the description of how the product should be used. They differ on a continuum in terms of the amount of additional data required to create each one.

  • Formal use cases require the most effort. There is splendor in them and there are many things happening in them, but they describe all the combinations of how different people perform the same activity (or its variation).
  • Informal use cases are more or less the same – just that they are less formal. The challenge is to provide an adequate level of detail, without elements that lead to formal use cases that are to be used as a reminder.
  • Abstracts of use cases almost have no additional data, but they contain the same challenges – how much is this enough? what informal use cases, but to a greater extent.
  • User stories have the least additional data and provide the smallest context.

Use case scenarios are a slightly different case. Like the user story, the usage case scenario describes one path through a multi-track use case. It is worth combining the weakness of the use case (high amount of additional data) with the weakness of the user story (limited context), which in turn will give a fairly consistent and agile and helpful artifact.

More from my site

  • User Stories vs Requirements When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification. While the user's […]
  • Three Benefits of Use Cases I recommend each person to use the use cases particular in Agile projects. Below three are basic advantages that I think will convince you to use the use cases in Agile projects 1. […]
  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]
  • The Requirements Are the Most Important During my work, I noticed that the requirements are a big problem. The difficulty is not to write them down. It is difficult to articulate them. I omit the turbulence associated with the […]

Leave a Comment

Your email address will not be published. Required fields are marked *