User Story
User story is a very generic definition of a requirement, containing just enough information for developers to reasonably understand the effort required to fulfill the requirement.
User stories generally include a short sentence that explains what the user does or needs to do, using simple and common language. They can be complemented with additional information about the requirement and acceptance criteria.
One of the key characteristics of this is that it focuses on what the user needs to do rather than on the functionality that the product or service should have. This creates an opportunity to discuss the solution and how it can provide value to both the customer and the organization.
User stories typically follow this format:
“As a user X, I want to be able to do Y, because Z.”
Here, X refers to the user, Y to what they want to do, and Z is the reason they want to do Y.
There are several advantages to using them:
-
- User Focus: When developing a product, it’s common to receive input from many individuals. These contributors may offer requirements that might not always hold significant value. By concentrating on the user rather than the preferences of the team and stakeholders, we can establish requirements that truly address the needs of those who will actually use the product.
-
- Needs-Oriented: The team develops products to meet needs. The user story clearly describes the need. This way, we can achieve better results and greater customer satisfaction.
-
- Flexibility: User stories require minimal documentation of requirements. This lightweight approach works well in complex and uncertain environments where changes are constant.
Characteristics of User Story
The co-inventor of this practice, Ron Jeffries, suggested a concept for developing user stories. This concept states that:
-
- Use Cards: A user story is just a short sentence written on a card to remind everyone of the story.
-
- Converse: Customers and developes refine the requirements in meetings throughout the project. It is during these meetings, between the team and the stakeholders, that decisions and ideas are clarified and recorded.
-
- Record Acceptance Criteria: The team should document the acceptance criteria of the story to facilitate its development and validation.
How to Build an User Story
As mentioned, a user story should tell a simple story about a user’s problem. In essence, it aims to briefly and openly explain what problem the user is trying to solve with the product. As we noted earlier, the user story uses the following formula:
“As a user X, I want to be able to do Y, because Z.”
Let’s explore the formula in more detail:
- User X: This is the person who will use the product. They are the one with the problem we want to solve by building the product. If there are several different personas, the team should write a user story for each one, even if they are very similar.
- Y: This is what user X expects to achieve with the product, i.e., their objective. At this stage, the focus should be on the user’s goal, understanding precisely what they want and only then considering how the product can help them achieve that objective.
- Z: This is the reason behind the objective Y. On a macro level, it describes the problem that led the user to have that goal. It’s here that we identify the cause that will guide us in creating or modifying our product.
For example, a real user story could be:
“John wants a bike lane near his home so that he can commute to work.”
In this case, the user is John. What he wants, or his objective, is a bike lane. His problem is that he needs a solution to commute to work by bike.
User Story vs. Use Case
Although user stories and use cases may be confused, they are not the same thing. They typically start in the same way, are anchored in an objective, are written from the user’s perspective, and are simple without telling the entire story. However, user stories emphasize the problem to be solved, the desired outcome, and the benefits we will gain. In contrast, use cases concentrate on how the system will operate.
Both contain the role of the user, objective, and acceptance criteria. However, user stories omit many details to allow for a more flexible discussion with stakeholders about how to solve the problem. On the other hand, use cases aim to define requirements in a more detailed and definitive manner.