A user story is one or few sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job functions. This is a high level definition of a requirement containing just enough information so that a developer could produce a reasonable estimate of the effort to implement it.
User stories are used with Agile software development methodologies as the basis for defining the functions that a business system must provide. It captures the "who", "what" and "why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for a business user as that user's primary way to influence the functionality of the system being developed.
User stories are a quick way of handling users' requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing business requirements.
During the process of collecting users requirements, a business analyst gets together with a users' representative to identify the specific needs of the business and create user stories.
As the customer conceives the user stories, business analyst writes them down on a note card with a name and a description which the customer has formulated. If the business analyst and the user find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory often using the INVEST guidelines.
The INVEST guidelines was created by Bill Wake as the characteristics of a good quality user story:
Letter | Meaning | Description |
I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story. |
N | Negotiable | User stories can always be changed and rewritten. |
V | Valuable | A user story must deliver value to the end user. |
E | Estimatable | You must always be able to estimate the size of a user story. |
S | Sized appropriately or Small | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. |
T | Testable | The user story or its related description must provide the necessary information to make test possible. |
User stories generally follow the following template:
As a "role", I want "goal" so that "benefit".
As a "user" I want to "do something" so that "I can accomplish goal".
As a "user" I want "function" so that "value".
There is also shorter version:
As a "role", I want "goal/benefit"
For example:
"As an estimator, I want to see all items I need to estimate this season so that I can see the volume of my work."
"As a user, I want to search for my customers by their first and last names."
"As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save."
It is very convenient to write user stories on cards which could later be arranged on a board to facilitate their discussion with a team. These discussions are important for the optimal project planning.
As a central part of many agile development methodologies, user stories define what is to be built in a project. User stories are prioritized by developers to indicate which are most important. User stories then will be broken down in tasks and estimated by developers.
User stories could be written with various details. Sometimes they describe too many functions. Such user stories are called epics. For example:
"As a user, I would like to be able to have documents workflows."
Such user story would be too large for an agile project to complete in one iteration. So, it would have to be split into smaller stories so they could be worked on in iterations. For example
"As a user, I would like to be able to send documents through a workflow to be approved."
"As a user, I would like to be able to send documents through a workflow to be reviewed."
Agile projects use a product backlog which includes list of functions in prioritized order for the development. User stories is very convenient and popular way to create product backlog. It is important to remember that user stories are not completed until they are discussed by a project team. Product backlog is not a replacement of the requirements document. User stories could help in creating the requirements document.
Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the user to validate it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.
Agile methodology favors face-to-face discussion over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:
- Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
- Allowing a developer and a user to discuss requirements throughout the project.
- Needing very little maintenance.
- Only being considered at the time of use.
- Maintaining a close user contact.
- Allowing projects to be broken into small increments.
- Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
- Making it easier to estimate development effort.
- Require close customer contact throughout the project so that the most valued parts of the project get implemented.
- They can be difficult to scale to large projects.
- They are regarded as conversation starters.
User Stories | Use Cases |
Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish. | Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system” |
Can be accompanied by Acceptance Testing procedures for clarification of behavior where stories appear ambiguous. | May be delivered in a stand-alone document. |