Following is a slightly edited excerpt from Beyond Requirements: Analysis in an Agile Mindset
What It Is
A user is anyone who receives value from a product. Users include people who directly interact with the product as well as those who do not directly interact with the product but receive some value from it.
User modeling is a technique used to establish a commonly agreed-upon list of user roles for a product. This list of user roles and their descriptions provides helpful context for user stories and other backlog items.
You can think of user modeling as one aspect of stakeholder analysis that is specifically focused on people interacting with a product or receiving value from it
An Example
The team working on the conference submission system modeled the user roles and used those user roles as an organizing concept for a story map. Following is a description of how we arrived at our list of users using the steps described in How To Use It. We did this as an exercise leading up to our creation of the backlog.
Brainstorm an Initial Set of Users
Each of us took a stack of index cards and wrote user roles on them, throwing each card into the middle of the table after we wrote it. This was to make sure that we didn’t get hung up too much on specific user roles too early. We ended up generating the list of user roles shown below.
Conference submission system initial user roles
At this point, we also included systems and roles on the team because we weren’t worried about filtering our thoughts yet. We figured those items might spark other user roles that we should include.
Organize and Consolidate the Users
Next, we organized the cards into groups that seemed to make sense, as shown below:
Conference submission system consolidated user roles
We also threw the following cards away:
- Submission system developer
- Agile Alliance executive director
- Agile Alliance board member
- Sched.org
- Sched.org developer
The reason? For the purpose of user stories, we didn’t want the people who are actually building the product to be one of the user roles. Generally, if they are going to use the product, they’ll fill some other role. We only want to include people who expect an outcome from the product in the user roles. If there is another system involved, it’s because there is someone who is accomplishing something as a result of that interface. Finally, we didn’t include the executive director and board member because when those folks use the product, they fill an existing role.
Refine the User Roles
Finally, we put together the short descriptions shown in the table for each user role so that we had a shared understanding of the characteristics of each user.
User Roles and Descriptions
| User Role | Description |
| Chair | Has overall responsibility for the conference program. The chair also acts as the administrator for the conference submission system. |
| Track chair | Has responsibility for selecting sessions for a given track in the program. Provides a final track recommendation to the chair. Also coordinates the review committee for his or her assigned track. |
| Track reviewer | Reviews submissions for one or more tracks and provides input on which sessions should be included in that track as well as provides feedback to the presenter on improvements to the session. |
| Submitter | Submits sessions to be included in the program and if selected will be the main presenter of the session. Can submit and edit his or her own sessions as well as respond to feedback posted to the session. |
| Attendee | General viewer of the submission information who may or may not attend the conference. Can view some session proposal information. |
When to Use It
User modeling is especially helpful when working on products with a significant amount of user interaction and where there are different types of users who can perform different activities or access different functionality.
It’s generally best to do user modeling when first starting work on a product. The discussions that occur during user modeling help to establish the range of potential users and can provide needed context. User modeling discussions can also provide some very helpful information for establishing scope. If your team is using one of the familiar formats for user stories, the list generated by user modeling provides selections for the “as a . . .” portion of those stories.
Why Use It
Consistent definition and use of user roles in user stories reduces confusion and helps to ensure that all cases are covered. The output of user modeling can also help with gap analysis.
If there are any user stories that have a user role that was not identified during user modeling, it could mean several things:
- There is a user role you forgot (new user).
- That user story is really not part of the effort (actual scope creep).
- You have the wrong user role in the user story.
If there are user roles without an associated user story, that raises different possibilities:
- You haven’t gotten to that user role yet.
- You are missing user stories.
- You have identified an extraneous user role.
How to Use It
There are three primary steps in user modeling.
1. Brainstorm an initial set of users.
Gather your team and ask them to write any users that come to mind on index cards (or sticky notes) and put them on a table (or wall). Don’t judge any of the suggested user roles at this point.
2. Organize and consolidate the users into user roles.
As a team, organize the cards into similar categories using whatever arrangement rules seem appropriate.
- Arrange the groups of cards spatially to indicate similar and overlapping users.
- Remove cards that represent users who are not relevant to the product. This includes users who are not impacted by the solution, or whose roles do not have any relation to the goal of the IT project. They could also be users whom you have explicitly removed from the scope of the project.
- Create a header card for each grouping that represents a user role for the solution.
- Refine the user roles.
Once you have settled on a list from the brainstorm, look it over and determine if any user roles seem to be missing. It may help to think of the kinds of user roles to “harden” the solution against:
- Abusers: Think of people who may try to abuse the product and identify features to prevent these abuses.
- Non Adopters: Think of people who will resist using the product and whether there are any features worth adding that may encourage them to use it.
When the team thinks they have identified all user roles, prepare a brief description of each user role so that the team will have a shared understanding of the characteristics of users. Your team may decide to create some lightweight personas as a way of structuring the descriptions.
Caveats and Considerations
User roles should not be specific real people but groups of people; for example, instead of “Kent McDonald” it should be “Claims Administrator.” If your team chooses to use personas, you may see names showing up in the persona descriptions, but remember that’s a tactic for making the persona more relatable, not identifying a specific person.
User roles should always represent people, not other systems. If there is a need for an interface between the product and some other system, someone receives value from that interface. Represent those people with a user role. Remember, you model user roles to identify the key roles that gain value from or can accomplish something with the product. The intention of identifying user roles is not to identify all the external agents that interact with a product (in which case identifying systems would be useful).
When you create user roles, think about what permissions they may have in the solution. Your user base may have many different titles that can do the same thing, such as Junior Claims Administrator, Senior Claims Administrator, and Claims Administrator First Class. In this case all of those users could be represented by the same user role. On the other hand, if there are people with similar titles who do different things—Claims Processor, Claims Entry, Claims Adjudicator—each of those may be represented by a different user role with different permissions.
Include as many team members as possible in the user modeling activity. They may have some perspective that the rest of the group does not, and the discussions that go into deciding what to ultimately call the users and how to group them together provide a great deal of information that’s helpful later.
Additional Resources
Cohn, Mike. User Stories Applied: For Agile Software Development. Addison- Wesley, 2004, Chapter 3, “User Role Modeling.”
Patton, Jeff. “Personas, Profiles, Actors, & Roles: Modeling Users to Target Successful Product Design.” http://jpattonassociates.com/personas-profiles-actors-roles-modeling-users-to-target-successful-product-design/.
Want to know more?
If you learn better with video rather than reading, you may want to check out Analysis Techniques for Product Owners Live Lessons, a set of video training sessions that show you how to apply analysis techniques to product ownership. Lesson 2.3 focuses on user modeling.
Analysis Techniques for Product Owners is available on Safari – O’Reilly’s online learning platform. Sign up for a 10-day free trial to view the video lessons.