User stories are another method for describing the behavior of a system. It is a technique that was developed as part of extreme programming and agile methodologies, in which requirements (“user stories”) are written as one or two sentences in the everyday or business language of the user. Each user story describes a meaningful interaction with the system from a user’s point of view. They are collected on index cards, so that they must stay very brief to fit on the card. The intent of the user stories method is not just to document system behavior, but to elicit conversations about it.
User stories are ideally written using a suggested sentence format of:
As a (role), I can (perform some action), so that (some goal is achieved)
For example,
- As an operator, I can check the status of a member, so that I can know if I should expect payment or not.
- A member can request a new ID card to be mailed to their home.
A few things to note:
- The roles do not necessarily have to correspond to a human. An internal or external system or process can play a role.
- User stories should be:
- Independent of each other (as much as possible)
- Negotiable – They are deliberately kept abstract and avoid details on purpose
- Valuable to users – the outcome of each story should be of some value to the user(s)
- Estimatable – they need to be small enough that a rough order of magnitude can be established
- Small – complex or compound stories about lengthy, hard to describe interactions need to be broken up into smaller stories
- Testable – there needs to be a clear way to know if a user story ended successfully or not
The acronym INVEST can help remember these attributes of good user stories.
Things to remember when creating a user story:
- Make sure to obtain a complete set of user stories, to ensure that the requirements are complete and correct, in order to define a product that will be suitable for use by the business. In particular you must ensure:
- All roles have been identified
- All interactions the users will perform have been identified
- The goals of each story is known
- Make sure the entire ecosystem of the project is considered with regard to user stories. Stories should include:
- The primary usage of the system (workflows, user interactions, interfaces between systems)
- Secondary uses of the system (administration, management, monitoring, reporting)
- Visible security concerns (what is and is not authorized)
Step-by-Step:
- From the scope document, write up the user stories you envision as you understand them.
- Identify the users and the roles they will play
- Identify the actions the users will take in their various roles
- Identify the goals of the actions
- Identify scenarios where each action should work and should not work
- Look for stories that need to be split or joined – check that the stories are Independent, Negotiable, Valuable, Estimatable, Small, and Testable.
- Arrange a review of the user stories by the business.
- Exchange the user stories documentation back and forth between yourself and the business, adding, correcting, or amplifying as needed.
- Make sure the requirements in the BRD cross-reference the user stories that support them.
- When the BRD is complete and the user stories are documented, review both simultaneously and obtain signoff for both.
Try to write your first user story and feel free to contact me or leave a comment if you have any questions.