Perfecting user stories into products
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. It should also provide relevant and needed information and document 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. Here’s an example —
“As an employee dashboard user, I want to login to the status dashboard, so that I can access relevant data pertaining to monthly reports”.
This 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 Create’s Product 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 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.
The unsuccessful path #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 #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 if 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.
Putting It All Together
To sum up everything we have covered, I’ll reference the image above. After outlining all personas and users, choose the appropriate user and frame the story from their perspective. For our example, I will use the employee dashboard user. The want here seems simple; it is just a log in. Famous last words…. The details are still important on simple features. By providing the right amount of detail, such as to `log in to the status dashboard`, developers are able to better understand the want. But the most important thing is nailing the so that. For our example, we clarify that the user’s real need is to `see data for monthly reports`. When developers and QA truly understand WHY the story is important, they can ensure the right questions are being asked and determine the correct implementation details.
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, and will allow better planning and easier implementation. It’ll also keep complexity and unknowns to a minimum.
