It’s a debate that has been raging in the world of Agile development for years: User Stories vs Use Cases. Are they the same thing? If not, which is better? Which is necessary? Should you use one or both?
As outlined in a 2012 post from Boost New Media, the general consensus is that User Stories and Use Cases are not the same thing. They may achieve the same outcome, but they do so in very different ways.
User Stories
According to the Boost post, a User Story is a short description of what your user will do when they come to your website or use your software. Dice goes a little more in-depth with that description, stating that it’s a high level or conceptual scenario. The example used is that a user needs to be able to save a report in two different formats. While the formats are different, Dice explains, the scenario is the same.
The Use Case Blog states that User Stories often start out the same way as Use Cases, in that each describes one way to use the system, is centered around a goal, is written from the perspective of a user, uses the natural language of the business, and — on its own — does not tell the whole story.
The pros: according to Future of CIO, it’s an informal process that should start with a simple sentence. As a (blank), I want to be able to (function of the system), so that (goal) can be achieved. By stating this sentence, the User Story then becomes the starting point by which Use Cases can be derived. User Stories are especially helpful for those who want the agility of adding value sooner and in smaller increments, explains The Use Case Blog. A User Story doesn’t have to be simple, however. According to Future of CIO, by using high level User Stories, User Stories can make for more productive planning sessions and a versatile way to add last-minute functions to the project.
The cons: One of the cons to using User Stories is that they often leave out a lot of details, relying instead on their conversational method of relaying details and time of development to the customer. This can be time consuming as this documentation is not complete upfront, as it is with Use Cases, but rather relies on collaboration that may or may not be present.
Use Cases
So what is a Use Case, then? It’s a set of interactions, Boost explains, between a system and one or more actors, with actors being people, other systems, or both. It’s a complete specification of all possible scenarios, writes Future of CIO. According to Dice, it’s a way of capturing the process flow or the steps involved in generating a report and the expected outcomes or alternatives. It’s a functional requirement that describes not only a behavior, but how that behavior can be achieved.
The pros: Use Cases have gone out of favor to the detriment of formalized concepts. Some of the concepts that the Use Case provides include the identification of actors and the ability to break the problem down into subdomains. In addition, Boost notes, there are times when the upfront research that is required for Use Cases is beneficial to the project and should be undertaken.
The cons: Use Cases are meant to provide such a formalized blueprint of the project, Future of CIO explains, that they often leave little room for negotiation or project additions. Additionally, states All About Agile, the Use Case can get a bit complicated and isn’t a format that is generally palatable for end users or business people.
User Stories, Use Cases, or Both?
Whether your project requires a User Story, Use Case, or both, depends on the project, the collaboration available, the level of formality, and the upfront research required. Some have found success in a hybrid, such as a highly detailed User Story, while others find the User Story as an important launching off point for the more detailed Use Case.
At Segue, we tend to employ Use Cases predominantly with government projects that have more stringent documentation requirements. For smaller, short duration projects we tend to lean towards User Stories. The many-years debate shows not so much that one is better than the other but that each can be applicable in varying degrees from project to project.