Write a User Story
Template
Use the following template to write your user story:
As a [type of user], I want to [perform some task] so that I can [achieve some goal].
What is a User Story?
[1] User stories are one of the primary development artifacts for XP project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP project stakeholders are called customers). As you can see in Figure 1 user stories are small, much smaller than use cases. In XP a user story must be able to be implemented by two people in a single iteration/cycle, therefore if you’re working in one week iterations each user story must describe less than one week worth of work.
[2]User stories serve the same purpose as use cases but are not the same. User Stories are written by the customers as things that the system needs to do for them. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.
[3]The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:
- Independent. Okay, for some systems, it's near impossible to make each feature completely independent. In other solutions, e.g. web sites, it's easier. But it's an important aspiration. User Stories should be as independent as possible. We're talking about minimizing dependencies rather than eliminating them, and at least allowing completefeatures to go into the build throughout the iteration.
- Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
- Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
- Estimatable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
- Small. User Stories should be small. Not too small. But not too big.
- Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
Prioritizing
[4] This is an interesting article by Mike Cohn at [Goat Software]about how to prioritize the product backlog.
- User Story: A description of desired functionality told from the perspective of the user or customer.
- Theme: A collection of related user stories.
- Epic: A large user story.
- Prioritize by theme.
- Survey users.
See complete DataShop Feature Wish List.
