One persona or many?

One persona or many?

Fleshing out the user needs is one of the most critical steps in the process of generating an Agile Story Map.  Sometimes it is easy to jump over the creation of user needs and the stories that are needed to satisfy those needs, and jump directly into the mechanics of building the Story Map, but you will not derive the same value in the end. Personas are an oft-practiced tool used to  help you focus on the generation of user needs and stories.

What Are Personas?

Personas are a metaphor for groups of systems users that were originally introduced by Alan Cooper. Roman Pitchler later suggested a template for a simple version of personas, which included: the persona name, a picture, behavioral characteristics, and business needs.  The first two categories help define the “who” part of the persona, while the rest describe the “why,” i.e. why the person would use the system. The concept of personas is used widely, inside and outside of IT.

The information used to define a persona varies by how the persona is going to be used. Thus there are many other, specialized versions of personas that include other data.  Examples of the other data include: capabilities, attitudes, involvement, age, location, likes and dislikes and technical comfort – just to name a few. I strongly suggest that persona you use be only as complex as it absolutely has to be. Use only the data that is relevant. For general IT projects, I generally use Pitchler’s template and then add location and technical comfort. (We will revisit this concept when we discuss gamification. There more complex personas may be needed.)  Always include a picture when defining personas.  Pictures help to draw in visual learners While I am not an artist, I feel that a hand-drawn picture is better than a photo to reinforce the idea that a persona rarely represents a single person, but rather is a metaphor for a group.

Mining or Defining Personas

Many Agile teams use User stories to delineate pieces of work.  User stories follow a pattern of “As a <user type>, I want to <function> so that I can <business value>.”  User type can be considered as generic starting point for defining a persona. If you use user stories, isolate the user types, group like user types together, give them a name and then complete the template for each persona.

Another place to start, if you have been using use cases, is to gather all of the “actors” that have been identified.  As with user types, group like actors together, name them and complete the template.

If you are not using use cases, user stories or any other user-centered documentation methods, start with a brainstorming workshop to identify the types of users and personas you and the software will be interacting with.  To help the session along, I use seed questions such as:

  • What departments will use this software?
  • What types of users roles are there?
  • What customers will interact with the software?
  • What are the goals type of customer trying to accomplish with the software?

When you have completed the brainstorming session use mute grouping (affinity diagraming) to cluster the roles.  Then name each distinct group and complete a persona template for each.

In Agile, personas are a tool that is used in many situations, such as developing user stories or generating an Agile Story Map. They can be used to focus the discussion of requirements, needs and stories on the types of people that will be interacting with the project or application. Because personas are named and tied to a picture, they are far less impersonal. It is easier for team members to feel a relationship.  The ability to relate to the people that the persona is a metaphor for improves our ability to put ourselves in their place and discover their requirements and needs.