User Roles, Personas and why they are needed

///User Roles, Personas and why they are needed

User Roles, Personas and why they are needed

On traditional projects, requirements are often gathered without taking into consideration the different types of users that may interact with the system. This is problematic, as functionality which may be useful for a specific type of user may be left out, reducing value for that user with the potential to impact revenues. Agile projects focus on the importance of identifying roles and understanding the impact they have on gathering and identifying stories. So, the first step in a typical story writing workshop is to brainstorm all the possible user roles for a product or solution.

Identifying Roles within a User Story Workshop.

The preferred way to identify roles according to Mike Cohn, User Stories Applied (2009) is to get the team (including the business) together to brainstorm all the possible roles that may exist for a system. We can do this by asking the team to take part in the following exercise :

  • Take a bunch of index cards and ask all team members to write the roles that come to mind one on each card.
  • As this is written, this should be placed on the wall or on a table, clearly visible to all team members.
  • During the session we do not try to limit or discuss the roles that are suggested.
  • After a short period of time, when all roles are exhausted then try to group the roles together for example, if we are building a travel booking system then we may have a group which may be related such as frequent flyers, business travellers, vacation travellers (all travellers).
  • Once the roles are grouped together, where there is team consensus that two roles are equivalent in terms of the functionality, these may be combined as a single new role which encompasses both roles, or one role may be discarded.
  • Once the roles are defined, then a description of the role can be added to the user role card. The description should focus on iteration and expectations from the system. e.g. The user is likely to be well versed with computers, but may be in a rush, and will want quick access to information, and navigation should be simple and accessible.

One Step Further : Creating Personas.

Within a user role, you may have different types of users or personas. It can be important to further categorise these, to highlight differences in usage or needs, here are some examples of personas of a User Role :

  • Grandparents (May impact timeout periods for example)
  • Children (May impact colours or child friendly adverts/content)
  • Hacker (May have malicious intent – security)
  • Visually Impaired (May need to avoid certain colours, or provide options for Visually impaired or disabled people)
  • Mobile Users (Content suitable for mobile ? or mobile app ?)
  • Impatient users (may result in double charging Credit Cards for example).
  • Stupid Users (Validation)
  • Information Hungry users (Content Rich)
  • Busy Users (Well laid out, with good navigation) … etc.

As you can see from the above examples of personas, it is quite likely if we just consider the role of a typical user, many of features may be left out. It does not mean that we must cater for all possible personas, but the process of examining each will ensure that we end up with a system which is most likely to be useful to our users.

Now we have identified all our roles and personas the next step is to gather the user stories associated with each role and persona.

By | 2017-09-16T11:08:17+00:00 June 5th, 2016|Agile, Scrum|0 Comments

About the Author:

I write about my experiences coaching and implementing SAFe in the real world. My focus is on real world implementation and lessons learned from companies across industry implementing Scaled Agile in their organisations.

Leave A Comment