User stories are an efficient way to communicate requirements about a desired feature. They are easy to digest, they focus on the important information, and they can expand in detail as you refine your requirements.
For a feature that will not be implemented in the near future, the feature can be a single sentence such as, “As a user I can change my password.” As your features get closer to development time, you can break them up into more specific user stories, such as “As an existing user, I can change my password from any screen so that changing my password is easy to find and perform.”, and “As a user who has forgotten their password, I can reset my password so that I can get into the application quickly.” and so on.
To add further detail, you can add Acceptance Criteria (sometimes called Conditions of Satisfaction) to your user stories. Acceptance Criteria describe specific User Stories. From the first example above, you might have criteria such as “A successful login directs the user to the home screen for their role”, “An invalid user name or password results in the message: “Invalid username or password.”” and “Forgot Password? link on Login screen redirects user to Forgot Password screen.”
- Writing of the User Story is not the end of the conversation it is merely the beginning.
- User Stories should be in the “voice” of the end user as if they have the new feature now.
- User Stories are quick to write.
- The User Story should communicate a need of the user without getting bogged down in too many details.
- The User does not know any technical terms and the User definitely does not know HOW the User Story is going to be accomplished by the developer. The user only knows what they want.
- The User Story explains the business value of the feature being requested.