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
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 ]
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 ]
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
[ 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 ]
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!