In theory, user stories are basically product features, requirements or tasks that add value to the end customer. But in practice, most Agile Teams use user stories as tasks that reflect what they are trying to accomplish, which of course is directed to meeting a customer need or requirement.
In theory they should be written like this: As a <user> (who) I want to… <what> so that… <why>
Example: As a front end developer I need to ensure the app is responsive so that it can work on different screen sizes
But using the format above to write user stories, requires more effort and space (which is limited if you’re using post-it notes). Plus it can get a bit repetitive and redundant, so…
In practice, most Agile Teams write user stories as short tasks which start with a verb: <verb> and the task that is being performed (written in a short and concise manner)
Example: Ensure the app is responsive so that it can work on different screen sizes
Examples of verbs to start a user story would be:
- Create
- Develop
- Build
- Plan
- Research
- Perform
- Test
- and so on
When writing user stories, you should include the story points + acceptance criteria for that user story in the system you’re using to track user stories (e.g. Trello or Jira) or in the back of your post it note if you’re using post its.
User stories should be independent, negotiable, valuable, estimable, sized appropriately, testable (INVEST).
Want to learn more about Agile? Read this EBOOK, listen to this AUDIOBOOK or enroll in this COURSE