A user story communicates WHO, WHAT, WHY and ACCEPTANCE CRITERIA of a product feature to a reader. A user story must be written with user in mind.
Structure of a user story
Who - User persona. It helps to create a list of applicable user personas along with the key characteristics.
WHAT - Clearly define what the story is supposed to do from a user's point of view.
WHY - Define the benefit achieved by the user.
ACCEPTANCE CRITERIA - A list of criteria that defines the story. Acceptance criteria must be written from a user's point of view. It will indicate every action a user will take as part of the story and system's response. It should also mention exception scenarios and error messages that user will be shown
Key considerations
- The size of the user story should be such that it can be implemented and tested in one sprint. Depending on the organization, the length of a sprint can be either one, two or three weeks.
- If a story can not be implemented in one sprint, consider breaking down the story is smaller stories such that they can be implemented, tested and used independently.
- Keep in mind the standard use case format : As a <WHO>, I want <WHAT> so that <WHY>
- Do NOT define HOW the story can be implemented in the user story.
Various stakeholders of a user story
- User experience designer (UX) team
- Engineering team
- Quality assurance team
- Documentation team
- Go-To-Market team
- Support team
- Operations team
- Other members of product team
Comments
Post a Comment