I'm going to be writing a series of articles about working with user stories on Dynamics 365 projects. In this article, we're going to be focusing on the user in your user stories.
I've never implemented Dynamics 365 for just one user (have you?). So I find it helpful to consider the type of users that raised the requirements I'm writing. Hopefully, you have lots of users and there will be groups of users with goals in common.
User roles were originally devised by Larry Constantine and Lucy Lockwood in Software in Use in 1999 as a collection of characteristic needs, interests, expectations, and behaviors.
Example User Roles
Here are some example user roles from a Dynamics 365 for Field Service project:
- Director of Parks Service
- Park Manager
- Park Ranger
- Marine Park Ranger
- Forest Park Ranger
- Maintenance Manager
- Maintenance Engineer
- Subcontract Engineer
- Asset Manager
Context, Characteristics & Criteria
When we're describing user roles, it's helpful to consider the role's context, characteristics and criteria.
- The context is the user role's physical environment, work situation, access method or device and frame of mind.
- The characteristics are the frequency of access, system experience, the complexity and volume of work.
- The criteria are the user role's primary goal and secondary goals.
In follow-up articles, I'll share more about how my teams come up with user roles, how we model them and document them. I'll also talk about personas, another option for describing users in our Dynamics 365 projects.