When writing user stories there are, of course, two parts: user and story. The user is embedded right at the front of stories when using the most common form of writing user stories:
As a I so that .
Many of the user roles in a system can be considered first class users. These are the roles that are significant to the success of a system and will occur over and over in the user stories that make up a system’s product backlog.
These roles can often be displayed in a hierarchy for convenience. An example for a website that offers benefits to registered members is as follows:
In this example, some stories will be written with “As a site visitor, …” This would be appropriate for something anyone visiting the site can do, such as view a license agreement.
Other stories could be written specifically for registered members. For example, a website might have, “As a registered member, I can update my payment information.” This is appropriate to write for a registered member because it’s not appropriate for other roles such as visitors, former members, or trial members.
Stories can also be written for premium members (who are the only ones who can perhaps view certain content) or trial members (who are occasionally prompted to join).
But, beyond the first class user roles shown in a hierarchy like this, there are also other occasional users—that is, users who may be important but who aren’t really an entirely separate type of user.
First-time users can be considered an example. A first-time user is rarely really a first-class role but they can be important to the success of a product, such as the website in this example.
Usually, the best way to handle this type of user role is by adding an adjective in front of the user role. That could give us roles such as:
-
First-time visitor
-
First-time member
The former would refer to someone on their absolute first visit to the website. The latter could refer to someone who is on the site for the first time as a subscribed member.
This role could have stories such as, “As a first-time visitor, additional prompts appear on the site to direct me toward the most common starting points so that I learn how to navigate the system.”
A similar example could be “forgetful member.” Forgetful members are very unlikely to be a primary role you identify as vital to the success of your product. We should, however, be aware of them.
A forgetful member may have stories such as “As a forgetful member, I can request a password reminder so that I can log in without having to first call tech support.”
I refer to these as decorated user roles, borrowing the term from mathematics where decorated symbols such as a-bar (x̄) and p-hat (x̂) are common.
Decorated users add the ability to further refine user roles without adding complexity to the user role model itself through the inclusion of additional first-class roles. As a fan of user stories, I hope you find the idea as helpful as I do.
Explore Further
Understand why the three-part user story template works and where it falls short.
See why developers should help write user stories before work reaches the sprint.
Story maps help to create a shared understanding of the product, visualize user needs, and elicit user story ideas. Discover how to create your own.
Get quick answers to common questions about user stories and acceptance criteria.
Get feedback on user stories, job stories, technical stories, and other backlog items. - **200 Real Life User Stories** - Retain the existing form block from the current User Stories page.
Compare user stories with requirements and use cases to see where stories help agile teams.