One of the most important questions we should ask ourselves before implementing software is: "What will users do with our software?" User-oriented solutions can help answer this question. Thanks to them, we can implement essential functions and protect ourselves from adding features users wouldn't use.
User requirements lie between the business requirements, which define the project's purpose, and functional requirements, which determine everything developers should use.
When choosing a method that will identify user intention and describe user interaction, things get complicated.
It would be best to use the two most popular techniques—use cases and user stories. Both strategies allow us to understand the requirements of users in many types of projects and perform much better than other solutions.
Do you want to know how much it costs to develop an app?
Use case versus user story: What are use cases and user stories?
Let's move on to the definitions.
What is a use case?
A use case describes the sequence of interactions between a system and a persona. The point is for the persona to achieve a goal, such as changing the profile data in an online store.
Each use case is a separate usage scenario that details the outcome a specific user wants to achieve. Use cases can help us understand a product's functionalities and requirements, providing information regarding how our product might be used.
In short, use cases in agile software development describe interactions between an end user and a system/product and help outline possible outcomes. This very user-centered approach allows us to see a product from the user's perspective.
It's also important to remember that a use case isn't a collection of multiple user stories. Instead, it's a combination of different approaches that can complement each other.
How should we write a use case?
An example of a use case may look like this:
Goal: Update customer profile
Actor: A customer of an online bookstore
Precondition: The online bookstore needs to have an "update profile" option
Standard path: The customer opens the bookstore's website and clicks on the customer profile icon. The customer enters their login information. Next, they navigate to the tab "account settings" and click on the "update profile" button.
Postcondition: The customer updated their customer profile.
Basic flow:
- The customer clicks on the "customer profile button."
- The system displays the profile settings.
- The customer proceeds to click on the "update profile" option.
- The system enables the customer to input desired changes.
- The customer changes their information and clicks "save."
- The system verifies if the information was correctly entered and saves it.
- The customer successfully updates their customer profile.
Use cases: Advantages
Use cases provide an understanding and structured visualization of user and system behavior. They can reveal how users perceive a product and how it might be used. Additionally, they help us communicate with team members, stakeholders, and developers. Thanks to them, everybody can see what a given feature should look like and function. Everybody is on the same page.
Consequently, use cases also make requirement validation easier and allow us to spot potential problems more quickly.
Use cases can help the development team think through all the possible uses of functionalities and challenges regarding their implementation.
Use cases: Disadvantages
The more complex the system, the more use cases we'll need to create, which can be challenging to manage. Creating use cases is time-consuming because it requires collecting requirements and scenarios and documenting interactions. Moreover, even if we strive to create a comprehensive collection of use cases, we might still overlook usage scenarios and system interactions.
What is a user story?
A user story is "a short and simple description of functionality, told from the perspective of the person, usually the user or client of the system, who needs a given functionality" (Cohn, 2010).
In agile development, user stories concisely describe the goals and needs of end users. They're typically written in simple language devoid of industry or technology-specific jargon. User stories can also be used to define acceptance criteria.
User stories can also be arranged as a map (user story mapping) to visualize the path a user goes through to achieve desired outcomes. Thanks to a user story map, product managers can more accurately prioritize work.
How should we write a user story?
An example of a user story template looks like this:
"As <user type> I want <a goal>, so <a reason>."
The user story format allows us to see the user's history (unlike the use case) and indicates their type and motivation for wanting to use a given option.
Therefore, we have a detailed description. For example: "As a customer, I want to update my profile information so that I can pay for my future purchases with a new credit card."
User story: Advantages
User stories foster a customer/user-centered approach because they focus on customers' perspectives and needs instead of describing how a system should react. As the product evolves and changes, more user stories can be added during development; they can also be modified, reflecting stakeholder and user feedback. As mentioned, user stories are written in simple language so that even non-technical team members can understand them.
User story: Disadvantages
User stories may lack the necessary context and be slightly ambiguous compared to use cases. Teams involved in a project may need additional information regarding the operation of functionalities. User stories don't provide details regarding necessary resources and estimated implementation time.
User stories must not be created in a vacuum for them to work; gathering user insight and feedback is essential to creating effective user stories.
Three C's of user stories
When creating user stories, we should remember three key aspects that comprise them.
Card
User stories are written on cards, either physical or digital. Our example above shows that they're one sentence long and meant to remind the team about users' goals.
Conversation
User stories can evolve through conversations with stakeholders and gathering user feedback. They can be constantly added and changed according to new requirements.
Confirmation
Confirmation occurs when the software is accepted or rejected based on the developed acceptance criteria. This allows us to determine whether given functionalities fulfill their objectives and work as intended.
Use cases and user stories: Other differences
Remember that the processes of use cases and user stories go in different directions, although both approaches have a user focus.
Working on a use case means the business analyst will work with users' representatives. They'll discover how a user imagines a dialogue with a system that aims to achieve a specific goal.
Thanks to the information collected, they'll create a structure consistent with the usage template. Based on the use case, they'll determine what functional requirements developers should consider. A tester will check whether the specific case has been correctly implemented.
The use case shouldn't specify the design details — its task is to focus on the user's perceptions. Use cases show the project participants the structure and context that aren't in the collection of user stories.
Agile teams typically focus on developing acceptance tests for user stories. Thanks to them, we learn how to meet the user's requirements. This method's strength comes from its focus on testing at an early stage of work—it results in very good outcomes, regardless of the methodology used.
We can create some really detailed user stories that can't be implemented in one iteration. Therefore, they must be divided into smaller stories that can be implemented in a single iteration.
Use cases and user stories: Common features
Let us now focus on the common features of both methods. First, use cases and user stories focus on what users want to achieve—not what they think the system should do. Our task—in both use cases and user stories—will be to describe the tasks that users must perform or identify user-system interactions.
The business analyst will find out what functions are necessary. Additionally, verification tests will assess whether a given option has been correctly implemented.
Uses cases and user stories: Which method should you choose?
Which method is better for product development? There is no clear answer to this question. Both user stories and use cases have their pros and cons. The choice between them depends on the type of project and stakeholders' preferences.
Use cases provide a more detailed description of how a user interacts with a system, allowing us to see the context more clearly. Thanks to them, we can determine the scope of a project and define tasks. We can often encounter them in projects where the waterfall approach is used.
In turn, user stories offer us a more user-focused approach and can help us outline project requirements. They facilitate task prioritization based on users' goals. They're usually used in agile software development.
That said, nothing stands in our way to use both approaches as complementary.
Where will both methods work, or where will they not?
Use cases and user stories will work for the following:
- Obtaining requirements for business applications
- Websites
- Self-service kiosks
- Systems that allow users to control devices
Use cases and user stories won't work for the following:
- Embedded systems and real-time systems
- Applications that use batch processing
- Computer-intensive systems
- Business analysis
- Data warehouses
User stories vs. Use cases. Summary
User stories and use cases are approaches that are incredibly helpful in both waterfall and agile development. They help us discover users' goals, needs, and perspectives and identify interactions between them and an application. They facilitate gathering insight and project requirements and ensure all project team members are on the same page.
With knowledge about their differences and strengths, we can determine which approach will be the most suitable for our current project, or they can convince us to use both.
Regardless of the decision, user stories and use cases are invaluable tools that make project management more efficient and effective.
Check out our articles devoted to choosing a good web development company part 1 and part 2.
Hero shot: Giphy.com
