4 Templates For Product Owners Looking To Write Great User Stories

The purpose of a user story is to describe the desired functionality of a specific part of the software.

This description should inform the reader about the type of the user, expected outcome or problem that needs to be solved.

This should be a conversation starter for the discussion which will happen during grooming or planning sessions. So the description should provide enough information for everyone to understand what is the task all about, but should avoid describing the solution.

Here are my 4 favorite user story formats:

1. Classic user stories

The classic format that almost every product owner uses is "As I […] , I want to […], so that I can […]". This is the one that is commonly used because is user-centric and answers a lot of questions. Most of the time, this format is excellent and can deliver all the information needed for the team. Let's do the breakdown and analyze each segment of this format:

As a [ type of user ]

This part of the template describes the persona. Defining a persona is important because it explains who will use this functionality. This context is valuable because it enables better understanding of the user. Understanding the user encourages team members to step into their shoes and think from their perspective. This makes it easier to understand the needs and problems they have, which leads to better solution.

I want to [ some goal ]

This part of the template is focusing on the solution or the actual functionality that needs to be implemented. The solution or the functionality is described from the users' perspective, saying what actions or steps needs to be taken in order to solve the problem at hand. This step should not focus that much on the implementation itself. That should be left for the discussion during the planning session. If you leave this part a little bit vague, it will not influence your team members opinions and you will get better ideas. Also, team members will be challenged to solve problems and will feel more engaged.

So that I can [ some reason ]

Important part of this format is the reason for making this functionality. This part of the template describes the reason why the functionality is needed for the user. It should describe the desired outcome for the users, the obstacle they are facing or motivation for using the software. If you understand this part, the basic need of the user, you will provide better solutions. This part is also important during the planning session, because it will keep the discussion on track when ideas start to diverge.

When to use?
When you have a software where different user roles are supposed to use the software in a different way, this format is a great match. It enables you to split areas of interest, user rights and user preferences. Also, this format is good at describing the user needs and wants, which sparks the discussion during the planning or grooming sessions.

2. Job stories

When you start writing user stories, you will probably notice that you can't always define the user for a specific functionality. Sometimes, the functionality is something that needs to be done after a certain trigger. For example, if the application crashes, call stack should be saved to the log file. In this example, there is no users, you can't really define them. Because of that, the previous format would not work. We could try and make something up, but that will just make the user story description sound awkward and instead of helping us understand the functionality, it would confuse us. This is where job stories come to play. This template is a job-centric template, focusing on triggers and actions rather than users and problems. Here's how it looks like:

When [ situation ]

Rather than describing the user, this part is focusing on the given situation. It provides the context for the reader and describes what just happened in the software. This is basically a trigger where something else is expected to happen after it. It can be anything from application startup to button click. In any case, this part of the template provides context for the user story readers, so that they can understand the situation and state of the software at a given point in time. This prepares the reader to better understand the job that needs to be done.

I want [ motivation ]

This part describes wants and needs. As mentioned before, this template does not focus on software user, but rather focuses on the software observer. In the example with call stack logging, the observer would be a person who troubleshoots a system failure. The motivation in this example would be "I want to have call stack in the log file". This is what the observer wants and needs.

So I can [ expected outcome ]

The outcome describes the purpose of this job. This makes it clear why do we want to build this functionality and what is the benefit of having it. This part is valuable when it comes to prioritization. Important outcomes will be naturally positioned on the top of the backlog. The value of this part of the template is having everybody on the same page about the sole purpose of the functionality. Understanding this will lead to better and often times simpler solutions.

When to use?
If the functionality is the same for every user, this is a good template to use, because you will avoid using "As a user" which sounds boring and brings no value to the statement. Instead of that, user story description is oriented towards the job to be done, which is more useful since it provides better context and the purpose of having this functionality.

3. Hybrid stories

This type is a slight variation of the previous two templates. Hybrid approach combines the two and focuses on the job to be done, but also specifies the user that will benefit from the described functionality.

When [ situation ]

This is the same as the previous template.

[ type of user ] want [ motivation ]

The variation here is having a specific user in mind. In the previous template, I've mentioned the observer instead of the user. Here, we actually have a specific person in mind. This is valuable when you have a couple of users that should use the software differently, so it is worthwhile mentioning their roles because the outcome is different.

So [ type of user ] can [ expected outcome ]

This part also has a specific user in mind, instead of the observer, because the outcome can be different based on the role. Note that this statement can have two different types of users, i.e. one user wants to perform an action and the other user expects the outcome from that action.

When to use?
When you want to focus on the jobs to be done, but you still have several users in mind, with their different expectations.

4. Technical user stories

Part of your backlog will always consist of pure technical user stories. In case of technical user stories, there is no users or wants and needs. It is pure technical task which requires different description. Not all software changes are user-facing, but they still need some kind of description. These are feature-driven user stories.

[ Action ]

This part describes the action that needs to be performed. It is often a technical term such as generate, create, install, backup, implement, revert, update, etc.

The [ result ]

This part of the template gives information about the result or the deliverable of the user story. The result is usually a piece of software, a class, unit test, input form, page layout, etc.

By / for / of / to an [ object ]

This part describes the context or the object that is created or modified. This is practically anything affected by the aforementioned action.

When to use?
This template should be used when the user story is purely technical. Most of the time, the title of the user story is self-explanatory, but it doesn't hurt to provide a short description by using this template. This can be used when describing changes to the API or generally any backend work which doesn't necessarily affect the user experience.

What's your favorite template for crafting user stories? Let me know in the comments!