Understood by the customer and end user Short enough that it consists of a few sentences

Download 121.46 Kb.
Size121.46 Kb.
What are 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

To avoid unnecessary complexity, they are often written on small index cards (real or virtual) called ‘story cards’ that outline the functionality using the form – “As a (role) I want (something) so that (benefit)”. For example, in an airline reservation system, a story card might look like:

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:

  1. 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.

  2. 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.

Share with your friends:

The database is protected by copyright ©hestories.info 2019
send message

    Main page