What is a User Story in Scrum?

A User Story is an informal, general explanation of a software feature which is written in end user's perspective.The actual purpose of this User story is to communicate the way a software feature will provide value to the customer.

User Stories are usually used to describe the product features and would form part of the scrum artifacts- the sprint backlog and the product backlog. In software development, product features would play an important role. These are the features that the user would want to use in the final product which are called the Requirements. The success of a software development project will lie in understanding the user requirements appropriately and accurately. Later they would be implemented in the final product. So, the requirements should be thoroughly known to the development project team.

In the year 1991, Kent Back has come up with the term "User Stories" for the Product features. According to him, a user story would be the one that describes what he or she wants rather than describing what the system can do for him or her. So, the view has changed from the product to the user completely.

In Scrum projects, the product Backlog would be a list of all the user stories. These user stories would be prioritized and would be considered into sprint backlog in the Sprint Planning Meeting.

Estimation is also based on User Stories and the size of the product would be estimated in User Story Points.

Why User Stories?

In Agile projects, requirements keep changing very frequently as teams and customers learn about the system based on the project's progresses. By using the User Story Approach, a big upfront design approach would be replaced with a "just enough" approach. User stories would reduce the time spent in writing the exhaustive documentation by focusing on customer centric conversations. Consequently, user stories would allow the teams to deliver quality software more sooner.

Benefits of using User Story Approach

• Simple and consistent format would save time when capturing and prioritizing requirements while remaining versatile enough to be used on small and large features similarly.
• Business values should be expressed yourself by delivering a product which the client really wants.
• Details should not be introduced too early which prevents design options and lock the developers inappropriately into one solution.
• Avoid the appearance of false clarity and completeness.
• Technical functionalities can be left to the developers, architects, testers and so on.

Basic concepts of User story

A user story is a lightweight method which is used to capture the "what", "why" and "who" of a product requirement.User stories would often contain fewer than 10 or 15 words each. User Stories are "to-do" list which would help to determine the steps along the project's path.They would make sure that the process and resulting product would meet the requirements.

A User Story is defined in three stages -

1. A brief description of the need.
2. Conversations which happen during backlog grooming and iteration planning to freeze the details.
3. The tests which confirm the story's satisfactory completion.

These three are the 3 C's which are the Card, Conversation, and confirmation.

User Stories- INVEST

INVEST would help in assessing the quality of a user story. If a user story fails to meet any of these criteria, the team may have to reword or rewrite it. A good user story should be- INVEST.

• Independent - It should be self-contained in a way which allows to be released without any dependency on one another.
• Negotiable - It captures the essence of user needs by leaving the room of conversation. User story should not be written like contract.
• Valuable - Delivers value to end user.
• Estimable - User stories should be estimated so that they can properly be prioritized and fit into sprints.
• Small - A user story is a small piece of work which could be completed in 3 to 4 days.
• Testable - User story should be confirmed through a pre-written acceptance criterion.

How to write User stories?

To Write user stories, a template is used which helps to ensure that you do not accidentally start writing technical tasks.

User Story template -

User stories would capture only the essential elements of a requirement -

• Who is it for?
• What it expects from the system?
• Why is it important?

Who - The user should be a human who interacts with the system?

What - The behavior of the system should be written as an action.

Why - The benefit should be a real-world result that is non-functional or external to the system.

Lifecycle of a User story

There are six main states for a user story throughout a software project -

1. Pending - User stories are found through the communication between the project team and user. At this stage, User story has nothing except a short description of the User's needs. There will not be any system logic, no detailed design of requirements, no screen design. The only purpose of user story at this stage is to remind all the parties about future discussion of user's request which is written in this user story. User card might be discarded in future when required.
2. To-do - Once the discussion between different stakeholders is completed, the user stories would be addressed in the next few weeks. Then, they are place in a time –boxed sprint. Such kind of user stories are said to be in To-do state. Detailed discussion is not yet carried out in this state.
3. Discussing - When a user story is in the Discussing state, the end user would inform to the development team to confirm the requirements as well as to define the acceptance criteria. Development team would write down the requirements or any decisions as conversation notes. UX specialist may create wireframes or storyboards to let user preview the proposed features in visual mock-ups, and to feel it. This process is known as user experience design (UX design).
4. Developing - After the requirements are clarified, the development team would start design and implement the features to fulfill user's requests.
5. Confirming - Once the development team has been implemented a user story, it would be confirmed by the end user. He/she would be given access to the testing environment or a half-completed product to confirm the feature. Confirmation would be performed based on the confirmation items written when detailing the user story. Until the confirmation is done, the user story will be in the Confirming state.
6. Finished - Finally, the feature is confirmed to be done, when the user story is considered in the Finished state. This would be the end of the user story. If user has a new requirement, either it is about a new feature, or it is an enhancement of the finished user story. The team would create a new user story for the next iteration.