<< Back to Requirements Management Home
User Stories
A user story is a form of software system requirement that has become quite popular in
Agile Methodologies such as Extreme Programming and Scrum.
Unlike more traditional methods such as a System Requirements Specification or Use Case Diagrams, the emphasis in
these methodologies is simplicity and changeability. Therefore user stories are designed to be easily described and
understood, and more importantly easily changed by the end customer during the project.
The attributes of a good user story are:
- Written using language that can be easily understood by the customer and end user
- Short enough that it consists of a few sentences and can fit onto a small card (read or eletronic)
- Focused enough that they describe small increments of functionality that can be completed in several days or weeks
- Frequently changed based on discussions with the customer as the functionality becomes better understood
How to Create
In accordance with collaborative, relatively information nature of agile methodologies, the user stories
are typically created by the developers and customer representatives either on paper or using an agile
project management system to capture the story. The customer is responsible for describing what they
want the system to do, and the developer is responsible for capturing the information and asking questions
to help clarify important points.
Unlike other methodologies where you have dedicated business analysts gathering the requirements,
ideally the developers should work directly with the customer to ensure that the user story is realistic
and technically feasible. Also since the developer will understand what it takes to actually implement
the feature, they will know which details need to be included in the story definition.
Compared to Use Cases
In many ways user stories serve the same purpose as a formal use case, namely to
capture system requirements from the perspective of a user of the system. Both describe the interactions that
occur between the external entity (user or actor) and the system. However despite these similaries, there
are some quite distinctive differences:
-
User stories are written fairly informally in the language of the user and have a loose, free-form organization
and are usually written by the customers in conjunction with the developers. Due to their informal nature, they can be subject
to interpretation and therefore require the customer to be on-site or available to clarify when necessary.
-
Use cases are written according to a fairly strict standard consisting of discrete steps that describe
the business process and the precise interactions between user and system. They are usually written by
business analysts on conjunction with the customer, but are prescriptive enough that they can be understood by
a developer without needing to contact the customer for clarification.
Importance of Acceptance Tests
As mentioned above, user stories by themselves are high-level descriptions of the intended functionality, and are
open to intepretation. Therefore they do not by themselves define the requirement in sufficient detail to form
the basis of a binding contract or a formal requirements specification.
Therefore user stories are typically accompanied by acceptance tests that
have been written by the customer (or at least agreed to by the customer) and will form the basis for the developer
to implement the user story.
Since the formal specification is embodied in the acceptance tests rather than the user stories, one key
aspect of agile methodologies (as compared to traditional waterfall development)
is that the development is specified by the results of the acceptance tests rather than the other way around.
As a result, the developers write the tests first and then develop the software to make the tests pass.
This approach is known as Test Driven Development and contrasts with the alternative, model
driven development or design driven development, in which the design model based on the "paper" requirements specification drives the development.