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 <user role> I <want/can/am required to> <some goal> so that <some reason>.

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.

In the comments, let me know what you think and please share some examples of decorated user roles you’ve used or encountered.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

Wow! Thanks for this Mike. I really learned a lot. this will make a great impact when I share this with my team in doing software development projects. good job!

Posted by Mary Dorreen on 2014-09-01 17:16:05

Hi Nicholas—

Thanks, I’m glad you liked this. I get the “but this story applies to others” often as well. My response is just like yours. And I like your examples—especially, “As a drinking player…” ;) Thanks for sharing them.

Posted by mikewcohn on 2014-08-31 17:58:07

Thanks for sharing Mike. These are great to help confirm ideas and attempts people are tying for user stories.

I try to add an adjective as often as possible just to help encourage everyone to consider the scenario and not just grab the primary parts. The only real negative response I have seen is - "This would apply to more than just X." Which of course is almost always true but lets focus on a scenario and see if that solution is applicable to all of those or if the different scenarios require different solutions. Or maybe there is the best of both worlds, but let's not start by trying to solve all problems at once.

Some that stick out to me that I have used:- "As a drinking player I need to know when the next break is so that I can decide if I can hold it for the break or identify the best time to interrupt play"- "As a miltitasking user I want a notification persisted until I have seen it because I may not be looking at the screen at the time"- "As a borrowing internet user I need the app responsive without consistent connection so that I can work at a coffee shop or using my neighbors internet"

Posted by Nicholas Tuck on 2014-08-31 14:10:38

Thanks, Matthieu.

I’m not a UX expert at all so I appreciate the list of advantages here from your perspective. I agree with each.

Posted by mikewcohn on 2014-07-13 21:14:46

Thanks, Kirsten. I’m glad you like this.

I will sometimes do something like you describe but in slightly different contexts. I might write “As a user who has just finished a search, I want to…” Both techniques can have their place.

Posted by mikewcohn on 2014-07-13 21:13:59

I agree. We've found ourselves in a situation where we'd bake the user hierarchy as a post-fix not prefix to the first part of the user story which becomes less consistent and is a little sporadic in it's approach. For instance, 'As a visitor, when coming to the site for the first time, I want, bla bla'. I like this approach which is more methodical... thanks mikewcohn

Posted by Kirsten on 2014-07-11 08:04:06

Working more and more on user experience focussed projects, I find the tip very useful.I think that using decorated users has an influence on the UX for the following reasons:- Instead of trying to think of all the possible scenarios for each 1st-class users, you first categorize and sub-categorize your users and - then - think about the situations they can encounter, which is a lot easier.- Your overall user experience (and UI and Information Architecture) will reflect this categorization. You will design for your general use and add the necessary elements for the sub-categories on top of this overall experience. Consistency, effectiveness, appropriateness to context are better achieved this way.- In my experience, any kind of hierarchy is always useful, as the main experience you create will focus on the important things, yet addressing the less common interactions, but on an other plan.Thanks again!

Posted by Matthieu Tournemire on 2014-07-11 03:37:50

Thanks, Priyadharshini-

Welcome to the agile world!

The most common template for a single user story is the form of “As a <type of="" user="">, I want <some goal=""> so that <some reason="">.” You can read about the advantages of that template at http://www.mountaingoatsoftwar...I’d also suggest looking at http://www.mountaingoatsoftwar... which shows how to use a simple spreadsheet to keep track of the user stories and to hide a lot of that boilerplate text to make stories more readable.

Posted by mikewcohn on 2014-07-10 22:09:24

Hello Mike, Greeting its such a useful message. I am new to Agile and looking for User Story Template. Can you share if you have any. Thanks

Posted by Priyadharshini Selvaraj on 2014-07-10 00:00:18

Thanks!

Posted by mikewcohn on 2014-07-07 09:28:08

Again a useful tip for product owners!

Posted by Knotwilg on 2014-07-07 08:11:49

Welcome to Scrum, David. I’m sure you’re going to love the agile way of working. For a feature that is desired for multiple roles, most of the time I will write the user story using the role that is most expressive of what needs to be done. Consider a typical travel website (book flights, hotels, etc.). It has roles of Business Traveler, Holiday Traveler [or perhaps Vacationer in the US], and more. I would write “As a Holiday Traveler, I can see photos of the hotel so that I can decide if it looks like the right hotel for me.” I’d write that at the level of the Holiday Traveler rather than Business Traveler even though both *could* look at the photos. I’d do that because the Holiday Traveler is (I believe) far more likely to look at the photos. I travel a lot for business and rarely look at hotel photos. I ask my clients where to stay, they tell me, I book the hotel. For vacations, though, my wife and I have spent hours fretting over whether a hotel is the right hotel for the trip. Occasionally I’d write a story like that at the higher level (as shown in the illustration for this post). For the travel site I might write, “As a traveler, I can…” If a story can be done by perhaps only two roles (out of more), I might write, “As a This or a That…” to make it clear that both can do it. Either way, the point of the selected role is to improve the conversation between a team member (or more) and the product owner. Good luck with your first Scrum project!

Posted by mikewcohn on 2014-07-04 21:59:07

Mike, I'm new to scrum and working with a developer to build a website. How do I deal with wanting one feature that I'd like designed for multiple user roles that may have different goals or values? I'm asking in terms of writing the story.

Posted by David O'Neill on 2014-07-03 20:57:11

Thanks, Zoran. Yes, this can lead to discovering new functionality, which, I think, is the main benefit of user stories in the first place. Thinking in terms of what the users want instead of system attributes (The system shall…) helps uncover that type of functionality.

Posted by mikewcohn on 2014-07-02 11:10:39

Good tip MIke

I find with this approach you would be able to discover some other functionalities that otherwise would be missed. I quite like your hierarchy regarding types of users