User Story is an another way of writing user requirements throughout a project
A User Story should focus on the who, what and why of a feature.
It describes an interaction of the user and the system, focusing on the value a user gains from the application. In other words, User stories will be in the form of short stories or simple description of a feature from the perspective of the User.
We have to schedule the meeting as usual to capture the Stories – In these meetings users will often to tell stories about the failings of their current system or process or why are we doing the project or they might tell stories about how they see things working better in future. We have to take this opportunity to capture these stories as User Stories.
- For e.g.:
- User Story: As a User, I want Servers to be secured & so it can be protected from Virus.
- Use Case: Servers are protected from Virus.
- BRD: Servers are required to be protected from Virus.
Each User Story should simply state what a user wants to do with a “feature” & should also contain “Acceptance Criteria” which determines when the user story has met the goal of the user.
Key Points to consider 100% User Story:
- Does User Story has a Story which has a feature of a application?
- Does it have a Value or Functionality, that user wants?
- Does it have Description?
- Does it have Acceptance Criteria?