User story
From Wikipedia, the free encyclopedia
A user story is a software system requirement formulated as one or two sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.
User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.
A user story is an informal statement of the requirement as long as the correspondence of acceptance testing procedures is lacking. Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled. Some formalization finally happens when the developer accepts the user story and the acceptance procedure as his work specific order.
Contents |
[edit] Creating user stories
When the time has come for creating user stories, one of the developers gets together with a customer representative. The customer is responsible for formulating the user stories. The developer may use a series of questions to get the customer going, such as asking if some particular functionality is desired, but must be careful not to dominate the idea creation process.
As the customer conceives the user stories, they are written down on a note card (e.g. 3x5 inches or 8x13 cm) with a name and a description which the customer has formulated. If the developer and customer find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory. However, it is stressed in XP that user stories are not to be definite once they have been written down. Requirements tend to change during the development period, which is handled by not carving them in stone.
[edit] Examples
As a customer representative, I can search for my customers by their first and last name.
As a non-administrative user, I can modify my own schedules but not the schedules of other users.
Starting Application The application begins by bringing up the last document the user was working with.
Closing Application Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save!).
| The consultant will enter expenses on an expense form. The consultant will enter items on the form like expense type, description, amount, and any comments regarding the expense. At any time the consultant can do any of the below options. (1) Once this is completed the consultant will “Submit. If the expense is under fifty (<50), the expense will go directly to the system for processes (2) In the event the consultant has not finished entering the expense, the consultant may want to “Save for later”. This instance should then be displayed on a list (queue) for consultant with the status of “Incomplete” (3) In the event the consultant decides to clear the data and close the form the consultant will “Cancel and exit”. This is instance will not be saved anywhere. |
[edit] Usage
As a central part of many agile development methodologies, such as in XP's planning game, user stories define what is to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers.
When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written.
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 customer to verify it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.
[edit] Benefits
XP and other agile methodologies favour face-to-face communication 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 developer and client to discuss requirements throughout the project lifetime
- Needing very little maintenance
- Only being considered at the time of use
- Maintaining a close customer contact
- Allow projects to be broken into small increments
- Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
- May be easier to estimate development effort
[edit] Limitations
Some of the limitations of user stories in agile methodologies:
- Without accompanying acceptance tests, they are open to interpretation which makes them difficult to use as the basis for agreement
- They require close customer contact throughout the project which in some cases may be difficult or may be unnecessary overhead
- Can have difficulty scaling to large projects.
- Rely more on competent developers
- User stories are regarded as conversation starters. Unfortunately they may not capture where the conversation ended and fail to serve as a form of reliable documentation of the system.
[edit] References
- Daniel H. Steinberg and Daniel W. Palmer: Extreme Software Engineering, Pearson Education, Inc., ISBN 0-13-047381-2
- Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5
- Mike Cohn: Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5
[edit] See also
- Acceptance test
- Extreme Programming
- Requirement
- Scrum (development)
- Use Case
- Agile software development
