The template for typical user stories is simple: “As a [persona] I want [goal] so that [benefit].” However, when you start writing them, it doesn’t take a long time to realize that it’s not suitable to describe all of your needs. Trying to force the user story template for all of your “requirements” will result in awkward and confusing stories. However, there is no need to limit yourself to the simple template (though it has its place), and becoming familiar with the various alternatives can transform your user stories into an effective tool to drive conversations around the intent of the end-user.
A Job Story, Problem Story, Improvement Story, System Story, and Feature Story are just some of the many alternatives that exist to the typical User Story. Knowing when to use what can help product managers create more impactful stories for the job at hand.
The key to creating successful user stories is not to focus on the template format, but understanding what the stories are designed to do. Once we understand their use, then the template can be transformed to suit our needs, paving the way for natural stories that drive meaningful conversations (make sure to include these 5 key elements to create simple, clear and impactful stories)
What are user stories? Are they even necessary?
One of the common mistakes that product managers make when creating user stories is to try and create a story for all of the features they have in mind. However, this will lead to creating user stories that all start to say the same thing. It is important to clarify that user stories are not about defining specific requirements but rather for driving meaningful collaboration and dialogue about the end-user intent. It has more to do with the problem (the “why”) than the specific solution (the “what”).
Let’s take a look at the three key components to a user story
- Identify the actual user persona
- Explain what their goals are
- Describe why these goals are important to them
So how does a user story drive the conversation? Let’s take an example.
As a delivery driver, I want to know the exact location of the building entry-point, so that I can park at the most efficient location for delivery.
As an engineer, I would immediately start challenging some of the ideas presented here. Some questions I might ask are:
- Are delivery drivers the only people that need this information?
- Is knowing the exact location of the building entry-point the best way to identify the best parking spot? Are those two things always correlated?
- Does this user story work for all building types (for example, a shopping mall)?
By asking these questions, we may find that the underlying assumptions of the user story are not true and that there is a more cohesive solution that can better address user needs.
The example above demonstrates the value of a user story- it isn’t to describe the feature or even propose a definitive solution, but to start forming a shared understanding of the context so that the team can be aligned behind the intent of the user. While this is not necessary for all product development, it is a powerful tool when done correctly.
User Story Alternatives
| Name | Format | Example |
|---|---|---|
| Job Stories | When [Situation], I want [Motivation] so that [Expected Outcome] | When my battery is low, I want it to show a warning message so that I can charge it before my device dies. |
| Problem Story | In order to [Solve Problem], we will [Build Solution] | In order to have more secure deployments, we will build a QA environment. |
| System Story | [Action Verb] [Subject] So that [Who] gets [What] or [Goal] is achieved. | Unlock the door when I approach so that I can enter frictionlessly. |
| Improvement Story | We have [Current Situation], we want to have [Desired Situation] | We have 3 steps to create a new user, we want just 1. |
| Feature Story | [Action] the [Result] [by/for/of/to/in] [Object] | Block new orders for items that are out-of-stock. |
Job Story: When [Situation], I want [Motivation] so that [Expected Outcome]
It might appear similar to a user story, but with a key difference. A job story is focused on the job that needs to be done, regardless of who the user is. It provides context for what is happening and what the trigger is. It is a great alternative to use when the user persona is not an important factor.
Problem Story: In order to [Solve Problem], we will [Build Solution]
Creating a problem story is a collaborative effort. The product manager provides the problem (in order to…) and the engineering team would collaborate to provide the second half of the conversation (we will build…). Here is a great post that dives deeper into problem stories.
System story: [Action Verb] [Subject] So that [Who] gets [What] or [Goal] is achieved.
When there is a very specific thing that needs to be done in a very specific way, a system story can be a useful alternative. While it is extremely clear and efficient, it leaves little room for conversation and should only be used if you are confident in the solution.
Improvement story: We have [Current Situation], we want to have [Desired Situation]
An improvement story is similar to a system story in that it specifically defines the outcome, the difference is that it refers to an existing solution that needs to be improved. By having an existing state, a lot of context is already provided and all you need to do is define the new desired state. Here is a great resource for more information.
Feature Story: [Action] the [Result] [by/for/of/to/in] [Object]
A feature story is another alternative that is focused on the solution. It is extremely clear and can be easily understood by both the product and engineer teams. The advantage here is that it can be easily broken up into smaller chunks of work.
Conclusion
To be fair, many of the alternatives mentioned here are not the same as user stories, since user stories focus on the problem. However, if you find yourself struggling to get user stories to feel natural, it might mean that it’s not the right format to use, and exploring the alternatives may give you more insight into what is more appropriate in your situation. At the end of the day, the templates that are provided are only guidelines and product managers should feel free to remix and customize them as necessary. Don’t be bound by the framework, rather use it to help you brainstorm ways to best describe what needs to get done.