User stories are a technique for communicating Product Backlog items.
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective. ^[https://www.atlassian.com/agile/project-management/user-stories#:~:text=software%20user’s%20perspective.-,A%20user%20story%20is%20an%20informal%2C%20general%20explanation%20of%20a,value%20back%20to%20the%20customer.]
User stories are not inherent to Scrum or Scrum Theory but are often used by a Product owner to help communicate and build out the Product Backlog and therefor should adhere to the rules found there.
Some thing to keep in mind when writing User stories.
- Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
- Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
- User personas — For whom? If there are multiple end users, consider making multiple stories.
- Ordered Steps — Write a story for each step in a larger process.
- Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
- Time — Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
The User story framework follows a set pattern. As a - I want to - so that The “As a” portion of the sentence addresses the individual. The person who we have identified as an indervidual who has needs. This may take the form of User personas which have been previously defined or it may simply by a user type, like “administrator” or