User Story: An overview

This is a short extension to the article on Requirement organization.

A user story is a tool used to capture requirements from an end user perspective. Every BA using agile methodology would already be aware of this tool. This is normally a single statement that defines which user wants what requirement and why. It can also be said to be a very simplistic description of a requirement.

Traditionally, these were noted down on post it notes or small bits of paper and posted on a discussion board. The reason for them being treated in such an off hand manner is that user stories take the pressure away from writing about requirements instead stressing on discussions about them.

There are quite a few benefits from writing user stories:

1. It keeps people's focus on what a customer needs and why they need it. In other words, attention is focused on business.
2. It saves time that is usually spent on heavy documentation and instead keeps the BA and development team focused on developing short and quick documentation.
3. Helps in easy capture and prioritization of requirement. A user story can be written during requirement capture phase itself and used for validation later.
4. Avoids introduction and analysis of requirements too early in the analysis phase. With user story, it is possible to write a single line and post it for analysis at a later date.
5. Since these are features broken down into its smallest components, they keep the tasks and estimates to be more realistic. However, it is important for the team to commit to what they can do and not be forced to meet predetermined deadlines.
6. It leaves the technical functions to the architect, developers and testers.

A user story is normally written in the format: As a <user>, I want <some goal>, so that <reason>. It can be written at one go but needs to be developed in incremental stages, a process which would include the below steps:

1. Brief description of what is needed.
2. Conversations that occur during backlog grooming and iteration planning. A track of these should be maintained in the story.
3. Acceptance criteria for marking a user story as complete.

The point 2 here could also be followed by documents on technical analysis, architectural documents, etc.

A user story should also follow the INVEST framework i.e.

1. Independent: Each user story should be independent i.e. it should be released separately without depending on other requirements.
2. Negotiable: There should be room for further adaptation and discussion for a user story.
3. Valuable: It should deliver value to the end users.
4. Estimable: A user story should be an estimable chunk of work such that it can prioritized and taken into sprint. For example, a sprint cannot just consist of one user story. If it does, then you are writing user story wrong.
5. Small: It should be a small chunk of work that can be completed in a maximum of 3-4 days. More than 5 days of development work for a user story makes it moot.
6. Testable: Acceptance criteria need to be clearly defined for a user story so that they can be easily tested.

Some examples of user stories are mentioned below:

• As a customer, I want to receive SMS when I place an order, so that I can be assured that the order has been truly placed.
• As a customer, I want to receive an SMS on the day of arrival of order, so that I can make arrangements to be available when delivery is being performed.
• As a manager, I want to receive a weekly report of the total orders placed per SKU, so that I am able to evaluate the performance of each SKU for making marketing and distribution plans.

A user story normally goes through the following lifecycle. This can be further refined based on the team's comfort. However, the following high level stages will need to be maintained.

1. Pending analysis: Here based on the discussion between various stakeholders, the user stories are written. However, they are not detailed. They are logged for future analysis and as a requirement. This serves only as a reminder at this stage.
2. To analyse: User stories are shortlisted for the next few months and are detailed. Once they are finalized, they are then broken down and described in detail. Clarifications are obtained during discussions and they are prioritized for completion in a sprint.
3. Discussion/Analysis undergoing: In this phase, the user stories are discussed by the development team and the BA. The acceptance criteria is discussed. Technical detailing is done and any clarifications required are mentioned in the ticket. UI/UX specialist may create wireframes or storyboards to present the mockups.
4. Ready for development: Here the user story is deemed ready for sprint. The acceptance criteria are agreed upon by all stakeholders. All requirements have been clarified and requirement confirmed by PO.
5. Developing: This is the implementation stage of the user story.
6. QA testing: Once the developer has completed the user story, it is rolled to the QA for further testing.
7. UAT: Once the QA has completed testing, this normally is made available to the PO or QA team at the customer's end for user acceptance. Sometimes, this could also be done by a group of beta users.
8. Completed: The user story is pushed to production or the merged environment and deemed fit for release.

The above mentioned points describe a user story in detail. If you need more information on how to perform user story mapping or on epics, features, etc., feel free to drop a comment in the comment section.