Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories to describe what a system or piece of software should do.  User stories have since been adopted by many of the agile methods used today.

User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the software or application.  They describe the users’ goals when using the system.  The initial descriptions can be written by the users, customers, product managers, or developers, and are just a few sentences at most (1-3 sentences being typical).   This isn’t the entire user story, but it is all that is created at first.  

The development of user stories occurs in three parts; the Card, the Conversation, and the Confirmation.

• The Card: Named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories (called story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development.  If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories.  The term used to describe a user story which needs to be further broken down into smaller stories is an “Epic”.
• The Conversation:  While the conversation itself is not an actual deliverable, it is a critical step in the user story development process.  Discussions about each user story are had with the users/customers of the system to flesh out details.  The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.
• The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented.  When index cards are used, the acceptance tests are typically written on the back of the card itself.  Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these three parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal.  If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

• I want to post a resume  
• I want to search for a job
• I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others.  One formal approach suggested by Mike Cohn follows the structure:  “As a (role) I want (something) so that (benefit)”.  At first, structuring your user story descriptions like this may seem like overkill sometimes, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY.

• As a job seeker I want to post my resume so that recruiters and employers can find it.
• As a job seeker I want to search for a job so that I’m in control of my job search.
• As a job seeker I want to electronically submit my resume for jobs I like so that I increase the changes of receiving an interview.

Here are some acceptance tests for the user story, “I want to search for a job”

• Test with keyword, salary, and location search parameters
• Test that the search results are returned in 2 seconds or less

Some comparisons can be made between user stories and use cases, but there are key differences that should be remembered.