There are many ways to document requirements. In today’s Agile-centric world, User Stories have become the popular and preferred method. While not exclusive to an Agile methodology, User Stories can help to express requirements in terms of the business value they provide. We employ Agile practices, and thus utilize User Stories in many of our mobile and website projects. Remember, requirements are meant to guide developers to create an application that fits a real-world business purpose. The software system must ultimately serve a user community, so User Stories are a way to define these requirements in their intended context.
Anatomy of a User Story
User Stories are simple, concise ways of detailing requirements from the perspective of the system user. They are composed of three parts: the Card, the Conversation, and the Confirmation.
The Card
The Card is the scenario of the User Story in its simplest form. It gives the Who, What, and Why of the scenario and is usually written out in the following format:
As a [actor], I want to [action], so that [outcome].
The Actor is the type of user who is interacting with the system. Examples might include “administrator”, “student”, “parent”, “end-user”, or others. It may be helpful to identify user types or roles (sometimes called “personas”) before you start creating user stories
The Action describes what the user wants to perform in the system. Examples might include “log in”, “pay my bill”, “search for classes”, or others. Actions, as their name suggests, should contain active verbs; and should be relatively short and limited in scope. Actions such as “View and pay my bill” should probably be broken up into two User Stories.
The Outcome explains why the action is important to the Actor. Examples might include “access my private account information”, “stay in contact with my friend”, or “pay down my debt.” Outcomes could be positive or negative (“so my account doesn’t get cancelled” is a perfectly legitimate outcome) but should always describe the value of the user story, from the perspective of the Actor.
The Conversation
The conversation fills in the details; this is where the team can elaborate on the User Story. Because the Card is limited to a single sentence following a specific format, the Conversation is critical to understanding the scope and details of the story and provides guidance on how it should be implemented.
The Confirmation
Confirmations are the steps or parameters for the User Story. These steps form the Acceptance Criteria that can be used to perform User Acceptance Testing (UAT).
A Healthy User Story
Creating User Stories is a seemingly simple process, but what makes a good User Story? For that, we refer to Bill Wake’s INVEST acronym:
I is for Independent: The user story should be self-contained, in a way that there is no inherent dependency on another user story (source).
User Stories should be independent entities. While completely eliminating dependencies is impossible (after all, they are describing features of the same system- you can hardly describe a hand without somehow addressing the fact that it attaches to the arm), you can minimize dependencies, and by doing so afford for more flexibility in their implementation.
N is for Negotiable: User stories, up until they are part of an iteration, can always be changed and rewritten.
A User Story should be negotiable, particularly in the Agile environment. Aspects of a User Story are defined, but the details should be open to continual adjustments. Specifications in a User Story are not fixed upon initial definition; they can and often do change until they are implemented. Once again, it goes back to the flexible and collaborative nature of Agile. When a User Story has been implemented, however, it is closed and if any further changes are needed a new story is created.
V is for Valuable: A user story must deliver value to the end user.
All User Stories should be of some value to the actors in the process, be it the system owner, users, financial backers or other effected parties. All parties involved should be able to see the value of why each User Story needs to be implemented. Going back to the User Story format, “As a [actor], I want to [action], so that [outcome],” if no discernible value can be seen in the User Story outcome, it should not be implemented.
E is for Estimable: You must always be able to estimate the size of a user story.
A team should be able to get together and estimate what it would take to implement a User Story. Estimation is valuable in determining the prioritization of User Stories and determining how to split the level of effort between sprints. If the team cannot estimate a User Story, it probably needs to be reworked because it is too large, too vague or there is not enough information available.
S is for Size-Appropriate: User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
User Stories should be small enough to implement in chunks. Exactly how small is dependent upon the team, but they should be small enough that X number can be implemented within a sprint, so a meaningful amount of functionality can be delivered to the client.
T is for Testable: The user story or its related description must provide the necessary information to make test development possible.
If a User Story cannot be tested, how do you know it is done? This goes back to the Acceptance Criteria listed in the Confirmation. The Team needs to collaborate up front to ensure that testable Acceptance Criteria are developed for the User Stories. This lets the Developers know what their code will be tested against, gives the testers guidelines on how to test, and gives the Team a measure for when a User Story truly is done.
Diagnosis
Healthy requirements form the foundation of development. Be sure to make your User Stories independent, negotiable, valuable, estimable, size appropriate and testable. Investing upfront in the health of your User Stories will make for a more effective development process.