Modelling User Roles

ParkRangers_600.jpg

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:

  1. Brainstorm your initial set of potential user roles

  2. Organise the potential user roles into groups

  3. 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:

1. Brainstorm

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.

In the 'Brainstorm' step of the user role modelling workshop the group has come up about 30 potential user roles for the Dynamics 365 Field Service project for the parks service.

In the 'Brainstorm' step of the user role modelling workshop the group has come up about 30 potential user roles for the Dynamics 365 Field Service project for the parks service.

2. Organise

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.

In the 'Organise' step of the user role modelling workshop, the group has arranged the roles into a column for executives with an interest in the system; columns of park ranger-type roles, technician-type roles and finance-type roles who will use the system; then taxpayers, visitors, pilots and park fire officers who might have an interest in the system.

In the 'Organise' step of the user role modelling workshop, the group has arranged the roles into a column for executives with an interest in the system; columns of park ranger-type roles, technician-type roles and finance-type roles who will use the system; then taxpayers, visitors, pilots and park fire officers who might have an interest in the system.

3. Consolidate

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.

In the 'Consolidate' step of the user role modelling workshop, the group has removed lots of duplicate user roles or user roles that had similar context, characteristics or criteria. The executive user roles have been simplified into one, 'Director of Parks Service'. 'Park Manager' was added, and 'Park Ranger' is a super-role for the 'Forest Ranger' and 'Marine Ranger' who have distinct context and criteria. Similarly, the 'Maintenance Manager' user role is new, and the 'Maintenance Engineer' user role is a super-role over the 'Subcontract Engineer' sub-role. 'Asset Manager' consolidates all the user roles with a financial interest in the parks' assets. The other potential user roles have been removed because they don't have sufficient interest in the system to make it worthwhile developing Dynamics 365 features for them.

In the 'Consolidate' step of the user role modelling workshop, the group has removed lots of duplicate user roles or user roles that had similar context, characteristics or criteria. The executive user roles have been simplified into one, 'Director of Parks Service'. 'Park Manager' was added, and 'Park Ranger' is a super-role for the 'Forest Ranger' and 'Marine Ranger' who have distinct context and criteria. Similarly, the 'Maintenance Manager' user role is new, and the 'Maintenance Engineer' user role is a super-role over the 'Subcontract Engineer' sub-role. 'Asset Manager' consolidates all the user roles with a financial interest in the parks' assets. The other potential user roles have been removed because they don't have sufficient interest in the system to make it worthwhile developing Dynamics 365 features for them.

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.

The context, characteristics and criteria documents the 'Park Ranger' user role in our Dynamics 365 Field Service project for the parks service.

The context, characteristics and criteria documents the 'Park Ranger' user role in our Dynamics 365 Field Service project for the parks service.

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?