User Stories:
As a (who?) I can (what?) so that (why?)
User Stories are a way of expressing software requirements in terms of what a user of your software can do.
They often take the form:
- As a (some role) I can (perform some function in the software) so that (I can acheive some goal I have).
As an example, some user stories for an email program might be:
- As a user, I can start a new email so that I can communicate with other email users.
- As a user, I can add a recipient to my email using an autocomplete function so that I can find recipients more easily.
- As a user, I can delete an unsent email so that I can change my mind about sending an email.
The parts of the user story answer the questions who, what, and why:
- As a (who?) I can (what?) so that (why?)
Helpful Links
- An overview from Mountain Goat Software’s Agile Guide Also read these four pages to which it links:
- Informal to Formal user stories: http://www.agilemodeling.com/artifacts/userStory.htm
- Various alternatives for the “As-a foo I can bar so that fum” format: https://en.wikipedia.org/wiki/User_story#Format
Videos
Advanced Topics, once you have the basic idea:
- The three C’s: card, conversation, confirmation
- Levels of competence with user stories: http://guide.agilealliance.org/guide/user-stories.html
- The INVEST acronym for writing good stories:
- Indepenent, Negotiable, Valuable, Estimatable, Small, Testable
- https://help.rallydev.com/writing-great-user-story
Related topics:
- User Stories: —As a (who?) I can (what?) so that (why?)
- User Stories: INVEST—Good user stories are: Indepenent, Negotiable, Valuable, Estimatable, Small and Testable