A user story is an informal, natural language description of one or more aspects of a software system used in software development and product management. It is a tool used in Agile software development to record a description of a software feature from the perspective of the end user.

What is the point of using user stories ?

Putting people first is a crucial component of agile software development, and user stories places end users at the center of the dialogue. Non-technical language is used in these stories to offer context for the development team and their work. The team understands why they are developing, what they are producing, and what value it generates after reading a user narrative.

They are frequently documented on index cards, Post-it notes, or in project management software. Depending on the project, user stories may be produced by customers, users, managers, or members of the development team.

The user story consists of three things:

Card: the story written from the end user’s point of view. The who, what, and why are all obvious. The card has no purpose other than to serve as a recollection of a discussion. You only have a limited amount of room to write what is most important.

Conversation: Before building a solution, developers should take the card and discuss it with the end-user to better understand their requirements.

Confirmation: Developers describe ways to indicate the problem has been solved during the dialogue. Then they document what is known as the acceptance criteria.

Not everything is a story

There are frequently business-driven or system-level needs that must be squeezed into the user narrative structure, despite the fact that they are not at all user-focused. It’s tempting to apply the user narrative structure to everything for consistency’s sake, yet it’s a poor match in numerous, frequent instances.

Sometimes security and technological standards are not the user’s primary concern, they are not reflected. It does not represent the business need of HOW the authentication should take place, but the user is unconcerned about it. It’s sincere, but it’s not very successful as a necessity.

Furthermore, it is also not about specifying specific criteria. User Stories are a technique for encouraging cooperation and ensuring that the most important aspect of any product or service is not overlooked: The End-User

When we have an issue to tackle or an opportunity to capitalize on, User Stories function effectively. They promote cooperation and assist the Scrum Team in developing the necessary shared understanding going ahead. But, User Stories, do not function well for tasks or issues. Writing bugs or tasks in the User Story style does not seem natural. User Stories, were not meant to handle bugs.

Example:

As a user of Hotstar, I want to find videos using the search filter so that I can find and select relevant videos from the search results and save my time browsing the whole catalog for the video I want to watch.

Web

• The web user wants to type and find videos using the search bar so that the user can watch the videos with the options selected by him/her.
• The web user wants to select and play a video from the search results so that he/she can watch the selected video.

Mobile App

• The Mobile user wants to type and find videos using the search bar so that the user can watch the videos with the options selected by him/her.
• The Mobile user wants to select and play a video from the search results so that he/she can watch the selected video.
• The Mobile user wants to see all the popular and trending videos on the app so that he/she knows the hot trending videos and watch them as based on their comfort.

Mobile app+Web

• The Web + Mobile user wants to see the Search History so that he/she can select the previous selected Channel/Language/Video/Genres.

Final Thoughts

User stories are a few lines that explain the intended goal in simple terms. They don’t go into specifics. Requirements are added later, when the team has agreed on them.

It is concerned with the experience – what the person using the product want to be able to do. A conventional requirement is concerned with functionality – what the product should be able to accomplish.

‍

‍