User stories are a foundational piece of agile software development and product development. They lay out the product’s requirements, but also allow each requirement to have a back story. Using the standard story format of “As a —-, I want —-, so that ——-” is a starting point, but answering this alone does not ensure a requirement will be understood and implemented as desired. A user story should always be an invitation to more conversation while providing relevant and needed information documenting expected behaviors.
Crafting the perfect user story title
A story can be written that satisfies the “standard format” and still provide nothing to the development team. “As a user, I want a login, so that I can login” is technically a user story, albeit a terrible one. A Product Owner may understand the relevance of this story, but chances are, others will not clearly understand what is being requested.
By providing more details, the request becomes much easier to understand. For instance, “As an employee dashboard user, I want to login to the status dashboard, so that I can access relevant data pertaining to monthly reports” allows the team the understand the context of the work being requested. Also, we have a better idea who the user is, how they will be interacting with the application, and why.
It’s all in the details
The key to great user stories is in the details provided. For personas, instead of using generic terms like “users” or “clients”, try to create something more meaningful. Who specifically is the user? An employee? A first time visitor? Having a clearly defined persona makes building the request portion of the story easier, too. Modus Kickstart book helps introduce personas and how to perfect them.
A request of “To login” may be enough detail if there is one kind of user and one kind of login. When this is not the case, provide specific details about what the user will be logging into, such as “to the status dashboard.” By adding this, it directs the user path within the application and helps be able to visualize what the users actions are.
The last part of a user story is the why. Giving the team this insight will allow them to understand the importance of the functionality. “So that I can login” provides only enough information to be dangerous. Instead, provide details to why the user needs this functionality, such as: “so that I can access relevant data pertaining to monthly reports.” That way, we clearly lay out the exact path the persona should take. This will help the developers understand the expectations of the story as well. Providing too few details will ultimately lead to more questions than answers.
Recognizing edge cases
The title of our user story is perfected. Let’s shift focus and lay out what the user experience will be and how they are using the product. For our example story, “As an employee dashboard user, I want to login to the status dashboard, so that I can access relevant data pertaining to monthly reports”, there are still a few more details we can provide to ensure the best possible understanding. This is easily accomplished by mapping out what the unsuccessful paths along with the successful path looks like.
The unsuccessful path pt. 1
“Given that I am an employee but do NOT have access to XYZ Product,
and I tap on the blue ‘login’ button on the top right of the header,
and I enter my employee username,
and I enter my password,
then I should see an error displayed under the login button with ‘Access Restricted’”.
The unsuccessful path pt. 2
“Given that I am an employee and have access to XYZ Product,
and I tap on the blue ‘login’ button on the top right of the header,
and I enter employee username,
and I enter a bad password,
then I should see an error displayed under the login button with ‘Invalid Username or Password’”.
The successful path
“Given that I am an employee and have access to XYZ Product,
and I enter my employee username,
and I enter my password,
and I click “Login”
then I should be directed to the monthly reports data.”
Mapping out unsuccessful paths allows the product owner to describe how the application should behave if errors are encountered or the user does not interact with the application as desired. A product owner’s goal is to have the best possible experience for the user. By providing this information to the development team, expectations can properly be set for desired and undesired behavior.
The “epic” user story
When a user story becomes too large and is no longer self-contained, it is time to break it up into multiple stories. It may seem logical to have a story fulfill every action that a user can take, but this becomes cumbersome to develop and test. For example, imagine you are designing a login page for your application. The functionality needed includes logging in with a username and password and the ability to reset your password. These two features are not dependent on each other. Instead, create an “epic” containing all stories related to a the login page, and create two stories–one for the login and another for the password reset. Smaller stories are more manageable and risk decreases with conciseness and self-containment.
Conclusion
Writing great user stories takes effort but will pay off quickly. User stories will fully document a product for the product owner. Developers, testers, and stakeholders alike will have requirements clearly laid out and understandable when the user story has adequate details and information. Keeping the story self-contained will ensure that the story is not too large will allow better planning and easier implementation while keeping complexity and unknowns to a minimum.
