Table of Contents
Agile development is all about adapting to the changes and keeping the client’s needs in the first place. It includes many frameworks and practices that are aimed at facilitating the development process (i.e. the well-known SCRUM) and clarifying the client’s requirements.
User stories and use cases are among the tools that help the developers deliver the expected results and make sure they correspond to the requirements. However, these tools often get confused or misused and, instead of the value, they bring additional problems to the development process.
As a company that actively works by Agile, SoftTeco will explain the difference between user stories versus use cases and will clarify when and how they should be used.
What is a user story?
In simple words, a user story is a short description of an action that the user will take on the website or in the application. It is also called a scenario as it displays the intended user’s journey – but not the whole one. A user story is basically a step in the user journey and all user stories are independent.
User stories are written in simple and understandable language with no technical phrases and consist of:
- The user: the person who performs the action
- The action
- The value: the reason for the user to perform the abovementioned action
If we take a mobile banking app as an example, it could feature the following user story: as a user, I want to pay my mobile bills online to save time. In this example, the user is the physical person, the action is the option to pay the bills via the mobile app and the value is that the user can do it in mere minutes from any place, without going to the office of the mobile service provider.
There is a concept of INVEST that is considered a must-have attribute for every user story. INVEST stands for: Independent, Negotiable, Valuable, Estimable, Small, Testable. These are all the features that a good and efficient user story should have.
The main goal of a user story is to help the client better communicate his ideas and requirements to the development team. As well, the user stories help the team understand the client’s vision, outline the desired functionality and ensure it works as intended.
To write a good user story, you need to do the following:
- Define the target audience and the possible needs
- Define the possible actions that the users will take during the interaction with a product
- Come up with a few options of the best implementations of the actions
Now that the concept of user stories seems clear, we can move to use cases and see what this tool is about.
What is a use case?
While a user story is a definition of a certain user’s goal, a use case describes how the user will achieve this goal. A basic use case model has an actor (the performer of the action) and the use case itself (the steps that the user takes to complete an action).
However, use cases are usually written in a more descriptive manner. A detailed use case may contain:
- a summary (the action itself)
- a rationale (why the action happens and what the previous actions were)
- users (action performers)
- a primary course of the event and the alternative courses of the event.
The alternative paths are needed to fully understand the user’s actions and consider all the potential actions too.
Same as user stories, use cases need to be written in plain and clear language. The main goal of this tool is to explain how exactly the user will perform an action and give developers certain guidelines to follow.
Comparing a user story and a use case
Though these two tools are independent and different, we can still compare use cases versus user stories for better understanding and clarification.
- Main point: a user story is about the user’s needs while a use case is about the user’s behavior.
- Complexity: a user story is less complex as it’s a simple description of a single user need. A use case, on the contrary, is more comprehensive and detailed.
- Content: a user story describes one action only while the use case incorporates primary and alternative actions.
It is important to understand that the user story and the use case are not interchangeable. And there is actually a bit of controversy about using these tools for the project.
While some development teams use either user stories or use cases, others claim that it is essential to use both. Judging from our point of view and experience, we can say that it really depends. Some projects need user stories only while other, more complex ones, would demand the use of both user stories and use cases.
Do you actually need Agile?
Sure, many companies work by Agile methodology – but does your company actually need to adopt it?
It all depends on the current state of a company and whether there are any issues that you wish to fix. For example, the top three reasons why companies switched to Agile include the wish to accelerate software delivery, enhance the ability to manage changing priorities, and wish to increase productivity, according to DZone.
As you can see, all three are quite common for the majority of software development companies and all three can be fixed by switching to Agile. However, there is a trap in this transition.
If you adopt Agile only because it’s trending, do not understand its core values, do not provide any training or education, then Agile will do more harm than good. As well, some projects cannot be broken into chunks so Agile will not be applicable for them either.
SoftTeco has been successfully working with both Agile and Waterfall methodologies. What we can say from our experience: estimate the project and identify the main pain points. It may turn out that it will be more cost-saving to actually work by the waterfall. The main thing to keep in mind is the project’s success and timely delivery of the expected results to the client.
Comments