Any product manager will tell you that the most important thing to consider when creating a product (or adding a new feature to an existing product) is how it will benefit the end user.
On the surface, that sounds pretty obvious. I mean, if you’re offering a product for sale, you’d want to know there’s a demand for it, right?
But it can be incredibly easy to assume your target audience will want your product simply because you believe it will help them in some way or another.
Unfortunately, this can lead you to develop a product that you think is useful, only to find that it doesn’t actually meet the needs of your target consumer. In turn, your sales numbers will likely fall way below your initial expectations.
Perhaps the best way to avoid this is to conduct research on your audience before you even begin developing your product. From there, you can create a user story that will help you develop a product that your customers will be dying to purchase.
What Is A User Story & Why Should You Create One?
In the simplest of terms, a user story is a statement made from the perspective of your end user that explains:
- Who they are
- What they want
- What they aim to accomplish by using said product
Though some variety exists in the way user stories can be framed, for the most part they follow this formula:
“As a (title or persona), I want (product or feature), so I can (benefit or outcome of using product/feature).”
Consider the following example:
“As a team lead, I need a project management tool so I can streamline processes for my employees.”
(Note: The above example is rather broad, and is only meant to illustrate the basic template of a user story. Actual user stories are much more specific. We’ll get more into this a bit later on.)
By creating a user story, you’ll inherently hone in on a specific customer persona, and be able to focus on developing a product specifically for that individual (rather than creating a generic product and hoping someone will want it).
This, in turn, will all but ensure customers who fit this persona will find your product useful. And, because you’ve anticipated the benefits your customers will reap by using your product, you’ll be able to gauge the effectiveness of it once it goes to market.
In other words, not only can creating a user story help you develop your product in the first place, but it’ll also set you on a path of continuous improvement of your product in the future.
Differentiating Between User Stories& Use Cases
Before we dive into how to effectively create user stories, it’s important that we differentiate between user stories and use cases.
A use case is a document that lists the step-by-step processes for using a product. Use cases are rather lengthy and complex, taking into consideration multiple users and scenarios. Use case documents often include the following seven elements:
- A summary of the product’s (or feature’s) functionality
- The rationale for creating the product/feature
- The user persona(s) the product/feature focuses on helping
- Prerequisite conditions for use of the product/feature
- The exact steps of using the product/feature
- Alternative pathways of usage
- The outcome of using the product/feature
A user story, as discussed and illustrated earlier, is much shorter and more focused. However, you might have noticed that many of the same elements are present in this much shorter document – specifically points 1, 2, 3, and 7.
While use cases act as a blueprint for actually using a product or feature, user stories focus mainly on the outcome of doing so.
(A quick note: Though we’ve positioned this section as “user stories versus use cases,” this is not to say that one is “better” than the other. In determining which you should use [or if you should use both], you’ll need to consider the scope of the project, the audience involved, and more.)
Creating A User Story
Though user stories in their finished state are short and to-the-point, their creation isn’t something to be taken lightly. In fact, the more time and energy you spend on creating an effective user story, the more likely you are to come away with an in-depth understanding of your target customer – as well as how you can develop your product with their needs in mind.
In this section, we’ll discuss two important aspects of creating user stories:
- Developing your understanding of your customer
- The facets of creating a user story through use of the INVEST model
Let’s get started.
Personas, Epics & User Stories
In his article From Personas to User Stories, Roman Pichler suggests a game plan for creating user stories that includes:
- Analyzing and choosing the right customer persona
- Developing “epics,” or broad user stories
- Honing in on specifics to create the final user story
Developing and Choosing Personas
As we’ve discussed before, customer personas are created by analyzing various characteristics of the individuals that make up your customer base, such as their demographic and geographic information, as well as their personalities and behaviors.
You’d then use this information to create a fictional profile of a “typical” customer or customers. For example, a company that sells equipment for outdoorsmen will likely have created a persona of a typical camper, and also one of a typical skier or snowboarder.
In turn, the company will be more in-tune with what products to offer each persona, as well as how to market said products to each persona.
When it comes to creating a user story, you’ll want to focus on one persona only. If you intend for a variety of personas to use the new product you have in mind, you’ll simply need to create more than one user story (rather than grouping multiple personas into a single story).
The reason for this is, different customers will use the same product in different ways, for different reasons.
Consider the following two user stories:
As a camper, I want a thermos that keeps my water cold, so I can stay hydrated on long hikes.
As a skier, I want a thermos that keeps my coffee hot, so I can get warm after a long day on the slopes.
Though the story revolves around two people using the same product, both are using it for almost completely opposite reasons.
But, even if the way in which two or more personas use your product align, you should still create separate user stories for each. Reason being, while a specific use of a product might be common between two personas, the overall experiences both have with said product won’t necessarily be the same.
For example, both a project manager and human resource director might utilize time-tracking software to see how much time employees are spending on a given task, the manager might be doing so to improve future project planning while the HR director might be assessing individual employees’ efficiency.
In either case, what will be done after using the software is completely different and independent of one another.
While you’ll most likely end up eventually creating multiple user stories for a variety of personas, begin by focusing on the main persona you’ve had in mind while brainstorming your product.
Remember the rather broad example of a user story we gave earlier?
As a refresher, it was: “As a team lead, I need a project management tool so I can streamline processes for my employees.”
In actuality, it’s more appropriate to call this example an “epic.”
An epic is a rough “sketch” of a user story that provides a general overview of each aspect of the story. In the example above, it’s clear that the target customer is a team lead or manager who is looking for a tool that will help them streamline processes for their team members.
But, a lot of questions are left unanswered, too. What does this team do? What type of tool is the manager looking for? What exact functions will help them streamline processes for their team?
Now, there will likely be more than one answer to many of these questions (and other questions, as well). Again, this means you’ll end up having multiple user stories under the umbrella of one overarching epic.
By defining the epic – and subsequently breaking it down into smaller user stories – you’ll ensure that each small task you complete when developing your product effectively goes toward reaching your overall goals.
Carving Out User Stories
Once you’ve created an epic, you can then “zoom in” to create more descriptive and usable user stories.
These user stories will help you develop individual features for your product that, when fully-implemented, will allow your customer to reach their stated goal.
Let’s go back once more to the example from above. User stories that go along with this epic may read something like:
“As a project manager, I want to easily assign tasks to keep my team members on track.”
“As the leader of a remote team, I want to communicate with my team members to know what tasks they’re working on.”
“As a project manager, I want to track time spent on tasks so I can better manage my staff.”
From these three user stories, you can derive that the hypothetical project management tool you’re developing should include features for assigning tasks, communicating with team members, and time-tracking.
Should one of these features be missing, your overall product most likely won’t meet the goal you’ve set in your overall epic.
The INVEST Model
As we’ve mentioned, it takes time and energy to create effective user stories. Despite their short length and overall simplicity, user stories can set your development team on track to greatness, or can derail a project altogether.
When developing user stories, you should ensure they are:
Let’s take a deeper look at each of these characteristics.
A single user story needs to be independent of all other stories within an epic umbrella. This will help avoid certain hang-ups during development, such as overlapping priorities or unintentional sequential prioritization.
Going back to our above example regarding the project management software, the three stories we created are completely independent of one another (i.e., each feature can exist without any of the others existing).
On your end (as the product developer), you wouldn’t need to, for example, develop the communications feature before creating the time-tracking feature (or vice-versa); you can tackle whichever one you choose first, then move on to the other.
Earlier, when discussing the differences between a user story and a use case, we found that use cases dictate the step-by-step processes of development while user stories simply care about reaching a specific goal.
This is because the process of reaching a user story’s goal should always be negotiable.
In our example, our hypothetical user wants to be able to communicate with members of the team. There’s no mention of how they’d like this communication to take place – only that they need a communication feature within the project management tool.
If, for example, the user can sufficiently communicate with their team through a real-time chat feature within the tool, there’s no need to add a video chat feature as well.
This goes back to what we said at the beginning of this article: You should develop products and features based on what your users want, not what you think they’ll want. In that same vein, you shouldn’t feel the need to add extra features that you think will “wow” your users if your users haven’t shown any desire to use these features.
The most important part of the formula we’ve discussed for creating user stories is the “so that” addendum to the end of the statement.
While the first two parts of a user story (the “who” and the “what”) are definitely important, as well, it’s this “why” that truly gives the story value.
Consider the difference between these two statements:
“As a project manager, I want to track time spent on tasks.”
“As a project manager, I want to track time spent on tasks so I can better manage my staff.”
In the first example, the reason the user wants to track time spent on tasks is a mystery. Since there are a number of possible reasons for this individual to want to be able to do so, the development team might have a hard time creating the feature in a way that specifically addresses the user’s needs.
On the other hand, the second example spells out exactly why the user wants to track time spent on tasks – allowing the dev team to create the feature with a specific end in mind.
A proper user story will give your team a good idea of the time and effort it will take to create the product or feature that meets the end goal.
Recall that, because user stories are (or should be) independent, you can prioritize them based on your own needs or preferences (rather than being forced to complete them in sequential order, for example).
Ensuring your user stories are estimable allows you create a timeline for working on and wrapping up a specific story or group of stories.
One thing to note here is that estimable doesn’t mean exact. It’s virtually impossible to know for sure exactly how long it will take to wrap up a story – and there’s really no need to, either.
Instead, estimate how long each story will take compared to each other; this will help you figure out which tasks to tackle first, and which ones to save for later.
When we say “small” here, we really mean “focused.”
Simply put: the smaller (or more focused) a story is, the easier it will be to complete. This is not just because a smaller story will require less “legwork,” but also because there’s a smaller chance of encountering problems or getting distracted by unforeseen circumstances.
When assessing the “size” of a story, a good rule of thumb is: If it’s not estimable, it’s too long. And, while there’s no set time limit for how long a user story should take to complete, the general consensus is that anything longer than a week should probably be considered an epic – and should be broken down into smaller user stories.
When creating a user story, one question should always be top of mind:
“How will I know when the story is complete?”
In other words, the goal for the user within a user’s story needs to be clearly defined so that you know whether you’ve done what you’ve set out to do.
In the example we discussed regarding communication, the goal is clear: Create a feature that allows remote team leaders to communicate with their employees to determine what task they’re working on.
As with the “Valuable” section above, it’s in the “why” part of the user story that makes it testable. Using this same example, even if you create a communications feature into your project management tool, if it doesn’t allow for effective, real-time communication, it probably won’t meet the user’s expectations.
Lastly, creating a user story with testability in mind makes it easy for your team to know when they’re finished with the task at hand, or whether they have more work ahead of them.
The process of creating a product can be a bit aimless if you don’t have specific goals in mind. And, even if you do manage to create an amazing, innovative product, there’s no guarantee it will sell if you created it without a specific user in mind.
By creating and developing user stories before you set out to design your product, you can determine exactly what consumers are looking for, and plan exactly what you can create that will help them reach their goals.