This article is part of the Effective User Stories Series.
If you’ve missed reading Part I: Why User Stories, Part II – What Are User Stories, and Part III – How To Write Effective User Stories, we strongly recommend you check them out first.
As we discussed in the previous articles, to deliver maximum value for our users, we need to be able to understand them. And often we have more than one type of user.
Naturally, different users may have their unique needs and we’ll have to specify User Stories for a concrete type of customer.
When it comes to writing effective User Stories, it is best to define the exact user we’re targeting. Writing down “As a user…” is not concrete enough.
How to define who is “The User”?
Defining User Personas is a great way to describe in detail who the user is. The team will understand what are the specific user needs, their context, pain points, and background. Ideally, you’ll give every Persona a name, for example, George, Anna, or Tonio, and you’ll put that name on the User Story Template.
How To Define a User Persona
There are many templates and approaches to writing down the description for your User Personas. In our experience, most of them will work. The important point is to have them and keep them simple!
Below is an example of a User Persona “Tonio” we use at AgilePool.
Tonio is a real person that we know very well. However, as long as it is better to refer to real people, it is not mandatory. It is fine to create a fictional character that describes the specific User.
User Story example with a User Persona
In order to use the system,
as Anna
I want to be able to login into the platform.
Writing your User Stories this way helps the team to empathize even more with the target user. It’s making it easier for them to understand for whom they are developing a specific functionality and enables them to be more creative and innovative.
Creating User Personas may seem time-consuming and some consider it expensive, but the benefits coming from their usage is unmeasurable.
User Stories with User Groups
An alternative for defining the user type is by using User Groups, like “Admin”, “Returning customer” or “First-time customer”. It’s a cheaper and relatively good approach. In this way, the team will have information on which type of group needs the functionality, but as it is limited, it is likely to miss most of the details regarding the user needs.
Example:
In order to pay easily,
as a first-time-customer
I want to be able to pay with my credit card.
It is possible to combine the two approaches to define the user role in different User Stories. You can have detailed User Personas for the most important or specific customers and having more generic User Groups.
So far, you’ve learned why we use User Stories, what is their purpose, and great techniques to write them powerfully and effectively.
It is equally important to avoid some of the most common mistakes when it comes to User Stories and this is going to be the topic for our next article.
Best From Both Worlds
It is possible to combine the two approaches to define The User role in different User Stories. You can have detailed User Personas for the most important or specific customers and having more generic User Groups.
So far, you’ve learned why we use User Stories, what is their purpose, and great techniques to write them powerfully and effectively.
It is equally important to avoid some of the most common mistakes when it comes to User Stories and this is going to be the topic for our next article.
