Tom “The Brewdog” Pinternick

Tom “The Brewdog” Pinternick

The goal of all software centric projects is functional software that meets user needs and provides value. The often-trod path to functional software begins at a group of personas, then to scenarios and then to user stories before being translated into software or other technical requirements.

Personas: A persona represents one of the archetypical users that interacts with the system or product.

Scenarios: A scenario is a narrative that describes purpose-driven interactions between a persona(s) and the product or system.

User Stories: A user story is a brief, simple requirement statement from the user perspective.

In Personas, Scenarios and Stories, Part 2 we generated a simple scenario for the “Brewdog” Logo Glass Collection Application:

When visiting a microbrewery, Tom “Brewdog” Pinternick, notices that there are logo pint glasses on sale. The brewpub has several varieties. Tom can’t remember if he has collected all of the different glasses being offered. Recognizing a potential buying opportunity, Tom opens the Logo Pint Glass app and browses the glasses he has already collected for this brewpub and discovers one the glasses is new.

After a team accepts the narrative story contained in a scenario the team needs to mine the scenario for user stories. The typical format for a user story is <persona> <goal> <benefit>. Using the scenario above, the first user story that can be generated is:

Tom “Brewdog” Pinternick wants to browse his glass collection so that he does not buy the same glass twice.

Much of the activity of this scenario happens outside of the application and provides context for the developers. For example one inferred user story for the context might reflect that since many brewpubs have muted mood lighting, the application will need to be readable in low light scenarios. This is a non-functional requirement. A user story could be constructed to tackle this requirement.

Tom “Brewdog” Pinternick wants to be able to see the app in low light situations so that so that the application is usable in brewpubs with varied lighting schemes.

Other possible ways to tackle this (and other) non-functional requirement includes adding criteria to the definition of done or by adding specific acceptance criteria to all user interface related user stories. For example, the team could add “all screens must be readable in low light” to the definition of done or as acceptance criteria for screens.

In both cases, these proposed user stories would need to be groomed before a team accepts them into a sprint. Grooming will ensure that the story has acceptance criteria and fits the INVEST (independent, negotiable, valuable, estimable, small enough and testable) criteria we have suggested as a guide the development of quality of user stories. Once a story has been created and groomed, the team can convert the story into something of value (e.g. code, hardware or some other user facing deliverable).

I am occasionally ask why teams can’t immediately start working as soon as they think they know what they are expected to deliver. The simplest answer is that the risk of failure is too high. Unless teams spend the time and effort to begin to find out what their customers (whether a customer is internal or external is immaterial) want before they start building, the chances are they will incur failure or rework. Agile embraces change by building in mechanisms for accepting change into the backlog based on learning and feedback. Techniques like personas, scenarios and user stories provide Agile teams with a robust, repeatable process for generating and interpreting user needs.

Time for new shoes?

Time for new shoes?

I recently picked up a guide to a large conference that included a set of personas to help attendees decide which tracks would be of interest to them. The goal for the conference organizers was never the set of personas, but the guidance they provided to the attendees. The path from persona to the end goal in software development and maintenance often runs from persona to scenario then to user story.   Once a set of personas are established, the next step in the flow is to generate a set of scenarios. A scenario is a narrative that delineates purpose-driven interactions between a persona(s) and the product or system. Most projects require multiple scenarios to describe functionality that needs to be delivered.  An example of a very simple scenario follows:

As Tim Trackman completed his daily 10k, he found that the eyelet on his favorite running shoes had broken. He decided to order a new pair of the same shoes  so that he could continue training for his next half-marathon on his phone while he drank a cup of coffee in the hotel lobby.

The scenario includes a persona, rationale for the goal-driven behavior and the context in which the behavior will be accomplished. Unpacking the example:
Persona:  Tim Trackman
Goal-driven behavior: “order a new pair of the same shoes  so that he could continue training for his next half-marathon”
Context: “on his phone while he drank a cup of coffee in the hotel lobby”

Several other scenarios could be driven out of the same basic context, for example would Tim’s behavior be different if his favorite shoe style was not available? As with personas, a simple process flow provides a disciplined approach to generating scenarios.

  1. Familiarize the team with the goal of the product or system and the previously defined personas. This step sets the context for developing the persona. Typically the context is delivered by the product owner or someone from product management.
  2. Develop scenarios of the personas using the product or system. The scenarios are stories that explain how the persona interacts with system, their motivation and the how the interaction affects them.  I typically recommend using small sub-teams such as the Three Amigos to initially generate scenarios. In larger projects that will have multiple teams, I break the group into subgroups. The facilitator should use the context from step one to get the team to generate scenarios that fit the context.

    Remember when to write each scenario from the point of view of a specific persona. Stay away from glittering generalities. For example, if a story is written in which a persona sometimes does action, press the team to define the reason. The team must explore the motivation of the persona that would make them perform the action. For example in our running shoe scenario, if the scenario includes “sometimes Mr. Trackman searches for a shoe” the facilitator would need to push to get the team to define what the motivation for the behavior might be. These will generally require either additional scenarios or user stories later in the process.

  3. Consolidate duplicate scenarios. Carefully consider nuances in behavior before declaring two scenarios as duplicates. Nuances can be variants in behaviors can require nuances in code.
  4. Build a scenario map. Lay the scenarios out as an activity flow. Actions should flow from left to right. In our shoe scenario, Tim would buy shoes and then later get the shoes and perhaps even later return the shoes. Scenarios that involve the primary persona should be on the top row of the map (this can be used to define the minimum viable product) and tertiary personas at the bottom.
  5. Review the scenarios. Review the scenarios with the team(s). Use the review process to validate the scenarios and fill in gaps. The review process will generate conversation that can be used to add details to the scenarios. In larger projects the review process can be done as a single group (difficult to arrange) or through a number of reviews with smaller teams. The later will require a step to integrate all of the comments and feedback into the scenarios.

Coming back to our Logo Pint Glass example, a typical scenario for the “Brewdog would be:

When visiting a microbrewery, Tom “Brewdog” Pinternick, notices that there are logo pint glasses on sale. The brewpub has several varieties. Tom can’t remember if he has collected all of the different glasses being offered. Recognizing a potential buying opportunity, Tom opens the Logo Pint Glass app and browses the glasses he has already collected for this brewpub and discovers one the glasses is new.

In part 3 we will generate a set of user stories from our scenarios.

Logo Glass Entry Screen

Personas are a tool to develop an understanding of a user’s needs. There are a number of ways personas can be used as teams develop and deliver value. The well-trodden path between personas and value is through user stories. The most effective way to navigate that path from personas to stories is using scenarios as a stepping stone. In the following two essays we will walk through a process to create personas, scenarios and user stories using the example of a beer glass logging app we have used in the past to describe Agile testing. The example is not meant to be complete, but rather to illustrate of the process the path form personas to user stories can take.

Generating Personas

Many articles on using personas to generate user stories begin with a step that is very close to saying, “get some personas.” When Alan Cooper introduced personas as archetypical users of the product or system being developed, he indicated that personas were to be generated based on research done on target or audience of the product. Unfortunately with out guidance on how to create a persona the idea of doing research has gotten lost. What most people need is a lean process for developing personas. A simple process flow to develop personas is as follows:

  1. Brainstorm an initial set of potential personas
  2. Gather data through research and interviews
  3. Refine list of potential personas
  4. Create the initial persona profiles (use template)
  5. Review, sort and prioritize personas
  6. Finalize (-ish) personas
  7. Post or share personas

Step 1 Gather a cross section of the parties impacted by the system or product. For small teams I generally recommend using the Three Amigos (product owner, lead technical and lead testing personnel), while in larger projects with multiple teams the group tends to grow to include product owners and leads from each team. Use one standard brainstorming technique to generate an initial set of personas. This list will be refined as the process progresses. Common seed questions for the brainstorming session include:

  1. What type of people will use this product or system?
  2. How will this product or system be used?

The goal of the session is to generate an initial list of persona names; however these sessions typically expose a huge amount of information. Write everything down; it will be useful later. The list of personas will not be perfect, nor will it be complete. Do not be concerned as the process uses a review and refinement process to ensure the end product is solid.

Step 2 Gather background information using the initial set of personas as a guide. Research can take many forms, including behavioral surveys, interviews and accumulated team knowledge. If you are going to use surveys to collect data to enhance your persona and you going use the data for product decisions, hire a market research firm or organizational psychologist to construct and execute the survey. The most common technique for internal IT projects is interviews. The technique is fairly easy, cheap and generally effective. I recommend creating a formal set of questions before beginning the interview process. The goal of all of the research techniques is for the team to develop a deeper understanding of users and how they will interact with the system.

Step 3 Refine the list of potential personas. Synthesize the original list with the research gathered in step 2 to update the list of personas. The consolidated list should weed out any personas that show substantial overlaps and expose gaps in the original list. In circumstances where the team does not know much about the system or product being built step 1 many not be possible until research is done therefore step 2 may be the entry point in the process.

Step 4 Create the initial personas by filling in the standard template we documented in Personas: Nuts and Bolts. I generally find that the process of completing the template continues the refinement process by identifying gaps and overlaps.

Step 5 Review the personas with the WHOLE team(s). Use this step to continue the refinement process and as a mechanism to add detail to the descriptions and behaviors documented in the template. Do not hesitate to add, change or delete personas at this stage. In larger projects with multiple teams begin by doing individual team reviews then consolidate the personas based on the input. The review process allows the team to share a broader perspective. A whole group review also creates a common vision of “who” the product or system is being built for.

During the review process prioritize the personas. Prioritization reflects the truth that not all personas are created equal, and some types of users are simply more important to satisfy. Prioritization provides the team with a mechanism to make decisions. Some of the personas represent critical stakeholders and others represent those that are less involved. Consider using a 3 level approach, with the top or primary persona being the most important to satisfy. The second level persona is important but not as important as the primary persona. I often find personas at this level provide direct support to the primary persona. The final category of personas is involved, but perhaps in a secondary support role. For example, a pilot would be a primary persona for an airline flight, the ground crew would be a secondary persona and the TSA agents would be a third-level role.

Step 6 Develop an agreement across the project that the personas that have been captured make sense and are as complete as they can be at this point. Always recognize that the personas can evolve and change. The act of generating a public agreement helps teams (or teams of teams) start on the same page.

Step 7 Post the personas on the team wall so that everyone can use them as a reference. In distributed teams post the personas on the wall in each team room and one the team’s homepage (Sharepoint, WIKI or any other tool being used).

Here is an example persona based on the Beer Logo Glass tracking application:

Persona Name: Tom “The Brewdog” Pinternick (primary persona)

Persona Name: Tom “The Brewdog” Pinternick (primary persona)

Job: Day job is QA manager, but at night he is a home brewer.

Goal: As a home brewer, Tom likes to visit microbreweries to get a broad exposure to different styles of beer. To mark visits to microbreweries, Tom buys logo pint glasses. Logo pint glasses can be expensive and it does not make sense to collect the same glass twice, therefore he needs to make sure he keeps track of the glasses he has purchased.

Personality: Brewing collectables, including pint glasses, is a badge of honor. Microbreweries without logo pint glasses are an anathema to the “Brew Dog.” A visit without evidence is a visit that never occurred (regardless of memories).

Lifestyle: Tom “The Brewdog” Pinternick lives with his foot on the accelerator, whether family or work, he tends to be single-minded. The balance between work, hobbies and family is important, but so is keeping score.

An archetypal user of dresses.

An archetypal user of dresses.

A persona represents an archetypical user that interacts with a system or product. Typically the first introduction a developer or product owner might have to the concept is when they are writing user stories in the form of <persona><goal><benefit>. If the concept of persona was just used in user stories they would be interesting, however personas have other uses. Other uses of personas include:

  1. Identifying requirements. Personas provide teams with a platform for developing scenarios that incorporate both who will use the system or product and how it will be used. Scenarios delineate purpose-driven interactions between a persona(s) and the product or system. The expectations, motivations and needs defined as part of a persona gives team members the information needed to playact solving problems as if they were an archetypical user. This allows the team to mirror real content and usage without tying the scenario to a specific system solution.
  2. Guiding decisions. As the development process moves from user story to delivered functionality, teams will make innumerable decisions. Personas help teams make better decisions by providing them with a tool to ground or justify a decision. I recently watched a team use a set of personas to make a decision about how they would structure a user survey. The team asked themselves how each persona would react to the design choice being considered. Several tweaks were adopted based on how the team felt the personas would react. The team in question keeps a copy of each persona on the wall in their team room and references the personas as a matter of course. A secondary impact of using a common set of personas to guide decisions is foe the team to align to the common goal of being user focused.
  3. Identifying releases.   While there are a wide variety of release strategies including continuous deployment and minimum viable products, teams and product owners often struggle with grouping functions and features for release. Personas can be used to identify which features and functions are related so that a release can used to solve a persona’s (or group of personas’) specific needs. I often use personas and the scenarios used to generate requirements to identify a minimum viable product.  Once a release candidate is identified I ask the team whether the group of functions being considered could be used by a specific persona and then whether the use would generate useful feedback. If the answer is yes for this part but no for another part, the release can be trimmed down to just the yes part. Alternately if the answer is no because we need something else, I generally start the campaign to increase the prioritization of that “something else.”
  4. Facilitating communication. All projects require well thought out communications. Personas provide the team with information needed to plan communications. Jo Ann Sweeney, author of the Explaining Change column on the Software Process and Measurement Cast strongly suggests that knowing your audience is a critical step in getting communications right (albeit she says it with a British accent). Personas are a tool to define your audience. The details of the persona’s needs, motivation and backstory provide a wealth of information needed to shape and develop a communication plan.

Personas are not just for user stories. Personas represent a lot of valuable information about who will use the system or product  the intrinsic benefit they expect. The information documented is useful across the entire development life cycle. A simple way of reminding a team that it really isn’t just about the system or product is to tape the personas to the project team room wall to create information radiators that remind the team that the users have an identity.

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.

Two completely different personas using the same system simultaneously.

Two completely different personas using the same system simultaneously.

Personas are often used in software development to generate and group requirements. For example, one of the classic constructions of user stories is: <Persona> <Goal> <Benefit>. The use of personas has become nearly ubiquitous. A persona represents one of the archetypical users that interacts with the system or product. Every system or product will have at least one archetypical user that can be identified. The concept of personas was originally developed by Alan Cooper in his book The Inmates Are Running the Asylum. Personas represent different behaviors based on research into the jobs, lifestyles, spare time activities, attitudes, motivations, behaviors and social roles. I am often asked where a team should get a set of personas given the level of usage (as if they were a set of playing cards), and once a team gathers the data, how that data should be captured.

In most internal development enhancement and maintenance projects, personas are developed using some form of brainstorming process. Brainstorming with affinity diagraming is a great tool to develop personas. The Software Process and Measurement Blog has described the process of Affinity diagraming. The people involved in generating personas are critical. The team you use to generate personas needs to have a broad experiential base. It needs to be cross-functional and diverse. The team needs to be able to take systems views of who uses the systems or product, otherwise the list of personas and their definitions will be incomplete. Second, when generating ideas in the brainstorming session someone needs to act as a facilitator and provide seed questions to the team. The seed questions will help the team to uncover groups of users and potential users, their needs, behaviors, attitudes and both work and non-work activities. In the grouping portion of the affinity diagraming process, the team should first think about personas when grouping and then when naming the groups ask the team to give the groups persona names. A further twist on the tried and true affinity session mechanism that I have recently found to be effective is to have the team break up in to smaller sub-teams to review what was done and re-brainstorm entries that could fill the gaps after the grouping and naming exercise. I generally time box the second step to fifteen minutes, although time-boxing may constrain innovation. When the sub-teams return integrate the new entries into the affinity diagram. The named and grouped entries from the affinity diagram will form the basis for the documentation needed to capture the personas.

Documenting personas might be the most contentious part of the process of establishing and using personas. Documentation smacks of overhead to many in the development community. I have found that if you don’t take the time to document a persona, it is far less useful. Documenting personas does a number of things. First the act of documentation allows the team to flesh out their ideas and drive out gaps and inconsistencies. Second, documentation helps the team to establish collective memory. Third, fleshing out the nuances fleshed out and establishing institutional memory makes it more likely that the team will refer to the persona after development because the investment in time and effort generates a perception of value. When documenting personas, ensure that you keep the documentation to the absolute minimum. I use a single sheet of flip chart paper per persona; not only does the single sheet feel lean, it also allows teams to post the personas around the room. Templates are good to for maintaining repeatability.

In Agile Story Maps: Personas we discussed and referenced a template defined by Roman Pitchler. There are a wide variety of templates for capturing information about a persona. In general they all include the following information:

  1. Persona Name
  2. Picture: a picture gives the persona visual substance and personality.
  3. Job: What does a person in this archetypical group do for a living (as it relates to the product or system).
  4. Goal: A definition of why the persona would want to use the product or system. Support of the goal can be found in the more personality and lifestyle (often written as backstory) of the persona.
  5. Personality: How does the group that the persona represents think, act, or react. This attribute includes motivation, attitudes, behaviors and social roles.
  6. Lifestyle: How does the group that the persona represents actually act? What does the persona do both at work and in their spare time?

Every template that I have seen (or created) is nuanced based on the needs of the team and the project. For example, the personas generated to guide developing requirements for an enhancement to a data entry application would be different from the personas needed to plan a major Agile conference. In the latter case more emphasis might be needed around motivation and lifestyle which would influence the speakers that might be accepted, social events planned and when the speakers and events might be slotted in the schedule. Teams use personas to help them think conceptually about the problem they are trying to solve without getting bogged down by having to think about and address each individual that uses the system or product as a special, individual case.

Personas are a tool help teams to understand a class of users by creating an archetypical user. Personas need to be identifiable and have back-story that includes needs and goals. The use of fictional people allows the team to dissociate themselves from the large number of individuals in the user base so they don’t get trapped in paralyzing detail. Personas need to be written down or you will not remember the nuances of personalities and lifestyles that make any two personas different.

User Stories are all about the conversation!

User Stories are all about the conversation!

A user story is a brief, simple requirement statement from the user perspective. User stories are narratives describing who is interacting with the application, how they are interacting with the application and the benefit they derive from that interaction. The classic format of a user story is:

As a <persona>, I want to <goal> so that <benefit>.

Personas are the different types of customers, users or consumers that interact with the system.  Personas represent any type of person including customers, user or consumers; or thing including other applications, system or hardware that interact with the system or specify the requirements of the software.  Personas help Agile teams make sure they are considering the needs of all of the classes of users, while also drawing boundaries. I suggest beginning the process of user story development by defining and/or reviewing a list of personas. It provides a platform for the team to define who is in scope and who is out of scope.

The goal is a simple representation for the work being done, not a detailed requirement. Ron Jefferies, noted Agile consultant, suggested the three “C’s” of User Stories.  The three C’s are attributes of a user stories:

  • Card,
  • Conversation,  and
  • Confirmation.

The conversation provides the details behind the story from the product owner and other stakeholders.

Simply put, the statement of benefit explains why the persona is pursuing the goal of the user story.  The benefit should be stated as specifically and tangibly as possible.  The product owner and team will leverage the benefit statement to prioritize the backlog of user stories.  Stories that do not have an identifiable benefit should be reviewed and refined until the benefit can be identified or jettisoned as a waste of time.

User stories are a mechanism to collect the needs of users so that a conversation can occur. Conversations are exchanges of thoughts, opinions, and feelings that take place as the stories are estimated, planned, analyzed, developed and tested.  User stories are a means to an end and not an end in their own right.