Many practitioners write user stories using the familiar template shown below:
The first slot in this template is for the user role, representing the class of individuals that receive the benefit provided by achieving the goal of the story. In a previous blog post I pointed out the importance of the goal of a user story being in sync with the user role in the story (See “User Stories: Match the Goal to the Role”). In essence, that guideline stated that for every story, the user role should be able to recognize, understand, and agree with the goal: The goal should match the role.
In this blog post, I want to focus on a different guideline having to do with user roles: choosing the appropriate role by balancing inclusivity and exclusivity. More specifically, for every user story, the user role should describe only those users who want to achieve the goal: no more and no less.
Here’s what I mean. Too often I see teams default to user as the user role for nearly every story. In many cases, user is too abstract—too broad, too inclusive. Instead, each story should employ the user role that includes all of the potential users of the functionality while excluding any non-users of the functionality.
As an illustration, consider the following user story:
When you read this story, does it make sense? Sure it does. The goal and role are in sync (the user of the system wants to research classes so she can decide on classes for the fall semester).
So what’s the problem? The problem is that I suspect user is too broad and too inclusive for this particular story. To be clear, there’s nothing inherently wrong with having user as the role. But user is a very abstract role. In fact, in many domains, user is likely the most abstract of all possible roles we could use. It implies everyone. And, generally speaking, it is uncommon that everybody is actually the user of a particular piece of functionality. More often than not, the true user of the functionality described by the story is a subset of everybody.
Challenge the User Role
When I encounter a story like the one above, I ask: “So, do all users of the system want to research classes, or do just a subset of the users want to research classes?”
This question is typically sufficient to get the authors of the user story to rethink who actually is performing the action in the story. Frequently the response is: “No, not everyone wants to research classes.”
So then I’d ask, “Okay, then which subset of users want to research classes?”
At this point, a typical response would be “students.”
Student would be a much better role than user to include in this story. In fact, in this case, I would argue that user is actually the wrong user role for the story because user is overly inclusive – it includes far more people than would actually use the feature being built. And, even if you don’t agree that it’s wrong, you have to admit that being overly abstract reduces clarity that could easily lead to development team confusion.
By using a more tangible role like student, it makes questions like “What else does a student want to do?” a bit easier to discuss and reduces the likelihood that we will miss important stories. Certainly this question is easier to answer than “What else does a user want to do?”
One final note on the role user. As I alluded to earlier, sometimes user might actually be the proper role. For example:
All users might have to login to the system; if so, then user would seem an appropriate role here. However, remember that after a user logs in, she is no longer a user. She might be an admin, student, or faculty member. So referring to her in a user story as user after she logs in is likely too abstract, and therefore too inclusive, unless all users that are logged in would use the feature described in the story.
Arrange User Roles into An Abstraction Hierarchy
In choosing the appropriate user role for each story, the goal is to find the proper balance between inclusivity and exclusivity. To accomplish this goal I find it helpful to organize my roles into a role abstraction hierarchy. Continuing with our school example, we might easily have a role abstraction hierarchy that looks like the following:
At the top (root) of the role abstraction hierarchy we have user. Under user we have a collection of more refined (specific) roles: student, employee (those who work at the school), enrolled parent (parents of students who are enrolled at the school), alumni, and so on.
Each of these roles could then be further refined. For example, perhaps it makes sense to distinguish among the students. For a high school, we might want to call out freshmen, sophomore, junior, and senior as unique and more specific roles. There could be features (user stories) that only apply to a certain student class. For example:
Alternatively, if this were a college system, perhaps is makes sense to further refine student to matriculating students vs. non-matriculating students (not shown in the hierarchy picture).
Choose the Role as Deep in the Hierarchy as it Make Sense
Once we have defined a hierarchy of user roles, we use it to select the role as deep down in the hierarchy as we can for each user story. So, if we think that a feature is going to be used by school administrators (e.g., principal, vice principal, etc.) then we should use administrator as the user role in the story associated with that feature.
To confirm we have the appropriate role, we would again ask the question: “Is this feature used by all administrators or just a subset of the administrators?” If the answer is that only the school principal would use the feature, then we should create a new role called principal that is a sub-role under administrator.
Then, to confirm that we have chosen a subset that is not overly exclusive (restrictive), we might then ask, “Will anyone other than administrators use this feature?” If the answer is yes, we should move up to a higher level in the hierarchy and use employee. For example, consider the following user story:
This story could easily apply to all employees (teachers and cafeteria workers want to take vacation too!), not just administrators, so this would be an example of where the role we chose was too restrictive (overly exclusive).
The goal is to select a role in the hierarchy that is as deep as you can. By that I mean that the role includes everyone you meant to include in the story and excludes any people who will not use the feature. If you find the user role you have chosen excludes some actual users, then you probably need to move up the hierarchy and choose a more abstract role.
Conclusion
In this blog post, I have proposed a guideline for user stories, namely that you should always strive to chose the appropriate user role by balancing inclusivity and exclusivity. In other words, use the most specific user role that you can—one that includes all of the people who will actually use the feature and none of the people who won’t.
To help you find the proper balance, I recommend organizing your user roles into an abstraction hierarchy where the most abstract role is the root of the hierarchy and more refined (specific) roles flow downward from the root. Then, for each user story, choose the appropriate user role by asking yourself two questions to balance inclusivity and exclusivity:
- Is this feature used by all of the people in this user role or just a subset?”
- Will anyone outside of this user role use this feature?