Today we'll be going over the basics of one of the most important tools a product manager can have. A user story is part of the agile methodology and communicates a product requirement in an easy-to-understand way. As opposed to traditional specs that group product requirements into a giant list, user stories are short and sweet descriptions of features written from the perspective of the person who wants the new feature or capability.
As a result, user stories shift the focus from just writing out requirements to having a more human conversation around the feature. [Tweet ""User stories shift the focus to a more human conversation around a feature.""] This is especially important because the end user experience is of tantamount importance to a successful product today, so writing from the point of view of a customer, for instance, helps everyone on the team to visualize how that feature will specifically impact that customer. That's what any product expert in the PMHQ community would tell you.
Here's a simple example template of a user story:
[Tweet ""User Story: As a [type of user], I want [some goal] so that [some reason].""]
As a [type of user], I want [some goal] so that [some reason].
So if I were to use an example from my work, a user story for a checkout project would look something like this:
As a customer, I want to be able to purchase an item online and pick it up in the store, so that I don't have to wait extra days for shipping.
The point of the user story is to clearly state the feature desired from the point of view of the user, whether that user is a customer, sales representative, or executive.[Tweet ""A user story clearly states the feature desired from the point of view of the user.""]
A user story must have just the right level of detail. A frequent mistake is to add too much detail into the user story when it should be a high-level requirement with additional detail added to the conditions of satisfaction. The conditions of satisfaction are usually more along the lines of a list of requirements that must be met in order for the feature to pass an acceptance test after coding.
Picture the user story as a branch on a tree and the leaves connected to that branch as the conditions of satisfaction.
If a user story is a branch, then the epic user story is the tree itself. In many large projects, product managers start off with a high-level vision written in the form of an epic story, which takes a longer period of time to complete and can be broken down into its constituent parts. So using the above checkout example, the epic user story could be:
As a customer, I want to have different options of receiving my purchases more quickly than the standard shipping method.
User stories are typically organized visually as cards, whether they're actual index cards or virtual cards from a project management software on the web. Some popular online versions include Trello, Mingle, and VersionOne. I encourage you to do some research on your own and check out some of the intro videos to get a better idea of how product managers (and other team members) typically work with these project management tools.
Be on the lookout for a future post detailing the story writing process and workflow in more detail!
Interested in learning more about user stories? You might want to check out our popular course: One Week PM. You’ll learn the fundamentals of product management, how to launch your own side project, and how to dominate product manager interviews.