What is a user story in agile?
User stories are basically part of agile development in which the focus is on discussing the problem rather than writing about it. User stories include writing the sentence and more important conversations about the desired functionality. This is a simple and short description of a certain feature from the perspective of a client, user or customer. In short, user stories are high level and slim requirements artifacts.
User story writing
As user stories can be written in varying levels of detail, it is easy to cover a large amount of functionality. For example, from a desktop backup product perspective, user story can be
- As a user, I can specify the files to backup based on the date modified, created and file size.
Who writes user stories?
User stories can be written by anyone. Although it is important for the product owner to add the user stories this doesn’t mean that he is the one who writes them. For an effective development of the product, user stories can play a vital role and for a good agile product, you should expect to have a user story examples that are written by each team member.
How to add details in user stories?
There are two ways to add specific details in user stories. One is to split the story into multiple and short parts and other is to add the conditions of satisfaction. When there is a large user story it is recommended to split it into short parts. This helps the developer to understand the requirements easily and effectively. It is also natural to assume in this way that the details have been added. The other way of adding details is a high-level acceptance test. This test has to be true after the agile user story is complete. For example, if a marketing user asks to choose a holiday season by reviewing the performance of past advertisements then such conditions should be fulfilled for the satisfaction of the customer.
When to write user story:
User stories can be written throughout the agile project. Usually, it is written at the start of the project but the user can add them over the course of the project. The reason for this is that with the passage of time, functionality and requirements can change. Some of the user stories in agile projects are Epics. These epic stories are later divided into smaller parts to help the developer in understanding the requirements. Additionally, the user stories can be written by anyone and at any time and can be added to the product backlog.
Epics (what are epic user stories?):
Epic stories are basically large user stories. These user stories are too big to be implemented in a single iteration. That is why they are reorganized into smaller parts. This increases the overall efficiency and productivity from the developer’s end.
These are basically a collection of related user stories. For example, for a university registration system, the attributes remain the same for every university. There can be a change of functionality but attributes are generally same. Themes are used to organize the stories into release and by organizing the stories it helps the sub-teams to work upon them.
Techniques to write user stories.
To create user stories there is an INVEST rule that is usually implemented. By invest, we mean Independent, Negotiable, Valuable, Estimable, Small and Testable. These are the features of the user stories that have to be considered while writing a user story. In most of the user stories, you will find that INVEST rule is followed very well.