Actors playing different roles.

Actors playing different roles.

Classic requirements definition techniques, such as use cases, use roles and actors show interactions and movement of data between systems. An actor is defined as an entity that plays a specific role within a system. Conceptually, actors in systems and products are not very different from actors in a theater. In both cases, an actor can play one role in one situation and another role in another. For example, David Tennant played the role of Dr. Who and then later played the role of Alec Hardy in Broadchurch. An auto mechanic (actor) might play one role when using a piece of diagnostic software and quite a different role when entering your bill into the cash register. Actors play roles to accomplish some outcome which make them valuable for defining and documenting use cases. Actors are less useful if they are used for eliciting and documenting user stories.

Agile requirements (typically documented as user stories) use the concept of personas to identify interaction with an application or product. Personas and actors, though related concepts, are not the same and should not be used interchangeably. Use cases focus on defining a specific process and how that process will be accomplished in a step-by-step process. A user story defines an outcome, who needs the outcome and the benefit they will received. Actors and persona can be easily confused. When confused practitioners can easily fall into the habit of substituting actors for personas or vice versa, which reduces the effectiveness of which ever process is used.

Two related differences are helpful to understanding why actors and personas are very different. The first is definition granularity. Actors can be a person, group or external system, and are generally defined in very broad terms, either as a name or a short title tied to an explicit role. For example, I recently reviewed a use case for entering a purchase order that included actors for a “purchasing department clerk”, “general ledger system” and “accounting supervisor.” The purchasing clerk enters the purchase order, a feed sent to the general ledger and the accounting supervisor reviews the data entered. A persona represents one of the archetypical users that interacts with the system or product. Personas can play multiple roles depending on their current needs and motivation. A related difference is the documentation granularity in Personas: Nuts and Bolts we defined a template that included name, picture, motivation, backstory and needs. Persona are far more detailed and structured to connection between the team and the persona. Actors are typically defined as a title (note some methods add annotations however these never rise the level seen when defining a persona hence the occasional whining about persona being heavy weight).

Persona are used in user stories and generally are more robust than actors. A persona is designed to help the team understand who they are developing a system or product. The detail allows the team to “get into the archetypical users head” as user stories and functionality is developed. Actors are primarily used in use cases which are used as a tool to develop flow or process based requirements. Use cases are also often used to validate designs and as tool to drive testing activities. In these scenarios the focus is how the work will be performed and in what order rather than on why and what needs are being met. The way actors are used does not require the level of documentation to be effective.

Actors include far less detail than a persona and typically are identified at a significantly higher level of abstractions. Based on the higher level of abstraction of actors, many personas might be summarized into an actor. Both actors and personas have value however if you are using user stories, actors do not provide a deep enough understanding of the needs and motivations of the users and customers of the system. Alternately when using techniques like use cases, developing profiles archetypical users replete with their back story, needs, motivations and picture is overkill. I learned many years ago that the right tool for the right job makes the job easier.