User Stories

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:
  • Advantages of the “As a user, I want” user story template
  • A Sample Format for a Spreadsheet-Based Product Backlog
  • Advantages of User Stories for Requirements
  • Non-functional Requirements as User Stories
• 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

• Introduction to User Stories (52 minute video)

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

---