User stories vs use cases: Are they the same?
User stories vs. use cases. It’s a common topic of conversation among developers, and product managers. Before I go any further, it is important to understand that user stories and use cases are not exactly the same.
User stories can be considered one of the most useful tools associated with agile methodology. Sometimes called a scenario or a requirement, the goal of a user story is to define the need of a specific user. To keep things simple, user stories are made up of a few short, but descriptive sentences. User stories are usually written by the customer. Typically, not a lot of time is put into writing user stories. For this reason, they are often vague, incomplete. Despite their inaccuracy, they are useful throughout the stages of development, as they help spark or initiate discussions with the customer regarding their needs and requests.
Advantages of using user stories vs use cases:
- You are always talking in terms of business value
- Keep things broad, so you don’t lock developpers into one possible solution
- Prevents you from introducing too much detail, too early
- Enables more “technical” members of your team to flesh out the details (i.e developers, testers etc).
A use case, also commonly referred to as a traditional requirement, is a simple way to describe to an end user how a system will be used or applied. Essentially, use cases are a group of or collection, of possible sequences of interactions that exist between a system and any other factors associated with that specific goal. Use cases are far more detailed, and contrary to user stories, are usually a collaborative effort between the development team and the customer. Unlike user stories, a lot of effort is put into the creation of use cases to ensure their completion and accuracy. Use cases help the development team paint a detailed picture of requirements, therefore eliminating the need to bombard customers with questions and requests for clarifications.
There are many business benefits associated with creating proper use cases:
- Ability to highlight and identify current goals, define systems and understand stakeholder needs
- Provide a detailed blueprint for analysis and design
- Create scripts that can be used in testing
- Help guide prototyping activities
- Identify and weigh risks
Source: (www.umsl.edu)
User stories vs use cases: Examples
Despite their differences it can be easy to confuse the two. Here are two examples to help illustrate the differences between user stories vs. use cases.
User stories
Generally a user story follows this template:
As a [describe who], I want [what], so that [why].
Example: “As a project manager, I want to create a project schedule, so that I know when all my tasks happen, so I can assign resources to them.”
Use cases :
Here’s a detailed use case of what happens when an ATM system starts up:
Example: “The ATM system will start up when the system operator switches to the “start” position. The operator will then be prompted to enter the amount of money in their cash dispenser. A connection to the bank will then be established. The operator can then proceed to serve customers.”
(Source: www.accelerateddeliveryplatform.com)
Just as I was trained back in the early 80’s to design COBOL programs in a format that would later be labelled “object oriented”, when I became a business analyst, the goal of my requirements elicitation meetings was to acquire the customer perspective in a format that would later be labelled “user stories”.
And though the works of motivational speakers are highly valuable and I very much recommend reading and listening at every opportunity, they are really just ancient wisdom articulated in books such as Proverbs and Ecclesiastes, as well as other sources from other civilizations. But they are much easier for the modern mind to “get”.
I understand what Solomon meant when he said “there is nothing new under the sun.
Regarding User Stories vs Use Cases, in a way a use case is to a user story what functional specs are to Business Requirements. It really just more clearly articulates and quantifies it. The user story is the starting point and, most importantly, gets the customer’s pain out front and on the table so that scope can be defined and requirements actually meeting the client’s TRUE needs can be created.
It’s nice to know that you are working from an understanding of WHY the customer really needs the project output in the first place. It not only improves quality, but increases job satisfaction.
And with a bit of tweaking, Use cased become test cases.
I was looking for some examples of User Stories for helpdesk type software when I came across this. I think it is a very interesting and concise explination of the difference and the reasons why they differ. Excellent stuff and it makes me want to keep watching for future posts by Catherine.