Modelling User Roles
In the previous article on user roles, I defined what user roles are and provided some examples from a Dynamics 365 field service project. In this article, I'll describe how I identify user roles for a system and how I document them for my agile Dynamics projects.
User Role Modelling Workshop
We usually only need to conduct a user role modelling workshop at the start of our Dynamics project. That's not to say the user roles modelled at the start of the project are fixed. We can add, remove and update user roles throughout the project.
Occasionally, I've run a second user modelling workshop after completing all the work for one division of an organisation before my team turns its attention to another division that has quite different user roles. But this is an exception.
The participants in your user modelling workshop are the product owner, any subject matter experts, and the development team. The scrum master can facilitate the user modelling workshop if required.
There are three steps in the workshop:
Brainstorm your initial set of potential user roles
Organise the potential user roles into groups
Consolidate and refine the candidate user roles
Here's an example of how the user role modelling workshop went for our Dynamics 365 for Field Service project for the parks service:
The facilitator grabs some sticky notes and begins writing down potential user roles names as people in the group call them out. Stick the notes to a wall. A potential user role is anyone who might use Dynamics 365, be impacted by it, or have an interest in the project or the system. No need for formatting or filtering. Don't worry about possible duplicates. Keep going until no one has any idea ideas for another potential user role.
As a group call out user roles that are duplicates or are very similar. Arrange similar sounding user roles together on the wall. Remove sticky notes that are duplicates of others. Discuss the meanings of the potential user roles to help clarify everyone's understanding. Keep going until everyone agrees all the potential user roles are in the right groups.
Consolidate any user roles that are almost the same. The goal is to have user roles that are highly distinct in their context, characteristics and criteria. Rename user roles to make their meaning clearer. Add any user roles that you might have missed. Organise the roles into super-roles and sub-roles where appropriate.
Documenting the User Roles
Although the manifesto for agile software development reminds us that we prefer working software over comprehensive documentation, I find a user roles model to be a useful document in my Dynamics 365 projects.
I recommend documenting each user role on one page or documenting all user roles in a large table and saving the page in your project wiki.
It is helpful to have your subject matter experts available to help the product owner document the user roles, so it's best to document the roles at the end of the user role modelling workshop instead of waiting until afterwards.
How many user roles should there be?
I'm sometimes asked about the right number of user roles for a project. But there isn't a perfect answer to this question.
I've worked on some small Dynamics 365 projects for a diverse group of users from different teams within the organisation. These might have had 100 users and 20 distinct user roles.
Other projects have been deployments into large sales forces or contact centres with thousands of users but a very simple set of 10 or so user roles.
Occasionally, we'll finish the user roles modelling workshop with a set of user roles that everyone has agreed on, but when we start thinking about user stories for each role we either realise that we've missed a role or two, or that some of the user roles all have the same stories and should be combined.
Job titles as user role names
In my Dynamics 365 projects, most user roles have names that sound like job titles. It's been easier for my teams to think along these lines.
Constantine & Lockwood originally imagined user roles like 'Park-Asset-Creator-Role' or 'Park-Asset-Repairer-Role' instead of 'Park Ranger' or 'Maintenance Engineer'. Job title sounding roles have worked well for me. What do you think?