Stories help you visualize your goals

Stories help you visualize your goals

In the Harvard Business Review article, The Irresistible Power of Storytelling as a Strategic Business Tool by Harrison Monarth (March 11, 2014), Keith Quesenberry notes:

People are attracted to stories because we’re social creatures and we relate to other people.

The power of storytelling is that it helps us understand each other and develop empathy. Storytelling is a tool that is useful for presentations, but also to help people frame their thoughts and for gathering information. A story provides both a deeper and more nuanced connection with information than most lists of PowerPoint bullets or even structured requirements documents. Here are just a few scenarios (other than presentations) where stories can be useful: (more…)

A puzzle and patterns have a lot in common.

A puzzle and patterns have a lot in common.

Stories are a tool to help structure information so that audiences can easily consume them. They help presenters make sure their message stays front and center so it can be heard. While many presentations and stories in the corporate environment use the metaphor of a journey, some are best represented in other ways. Other patterns are useful both to fit other circumstances or as a tool to inject a bit of variety into presentation heavy meetings. (Just how many journeys can you take in any one meeting?) (more…)

1481640068_942af9e1e4_b

The Mountain is one example of a journey-based story structure.

Presentations are a story that the presenter is sharing with an audience, and any good story has a beginning, middle and an end. All too often the beginning is a slide that has an agenda, the middle is slide after slide of data and the end is a slide titled conclusion or questions.  Across that arc, the presenter seeks to inspire, informs or persuade. A better approach is to use one of the tried and true story structures. A story structure is often a useful tool to ensure the audience stays attentive and hears the specific points the presenter is trying to make. The presentation does not need to be the next The Lord of the Rings, but you could or should emulate those plot patterns.

The Monomyth or The Hero’s Journey is one of the most common story structures. The monomyth is cyclical story structure in which a hero team embarks on a journey and then returns when successful. It describes where the journey started, the trials along the way, the goal that was attained and the steps to move forward after the goal has been met. The hero’s journey was originally introduced by Joseph Campbell in The Hero with a Thousand Faces (1949). It is a broad narrative structure that can be used when the presenter is leveraging a journey metaphor, one of the most commonly used stories in business and conference presentations.  The journey is commonly used to describe process improvement, methodology adoptions or business transitions. I tend to leverage a version of the monomyth pattern described by Christopher Vogler that has twelve steps in order to provide a journey type of structure to relevant presentations. (You can view a recent example of how I applied the monomyth to a presentation in Discover The Quality of Your Testing Process). Reflect on every adventure movie you have ever seen and you will recognize the pattern. Even in a business environment, audiences are very comfortable with this approach because they have been trained to recognize the pattern.

Similar Journey Story Narratives:

Freytag’s Pyramid is a structure that follows a similar pattern of rising action climax, falling action followed by final release. This pattern is commonly used in commercials to hold attention (here is an example). In this pattern, the protagonist doesn’t need to return to complete the cycle, but the problem does need to be solved. I often use Freytag’s Pyramid as a guide to ensure short presentations have a plot.

The Mountain begins by describing a current state, showing how challenges are overcome as the story moves away from the current state towards a conclusion/climax, followed by falling action. The most significant difference between the Hero’s Journey and the Mountain is that in the Mountain the conclusion does not have to be positive. For example, the Harry Potter series would have been much less of a Hero’s Journey and more of a Mountain if Voldemort had won. Similarly, the mountain would be a good structure to use to describe an Agile adoption journey that ended in implementing a new waterfall methodology. 

It is easy to see how to use the journey story narratives to tell a story of great quest; however, in a business environment, journey story narratives have a wide range of uses.  Some of the typical business uses are:

  • Establish that change has happened in an organization.
  • Make sure that the audience understands that the progress made was not easy.
  • Show that taking a risk had benefits.
  • Identify the source of new information and knowledge.

 Story patterns like the Hero’s Journey, Freytag’s Pyramid or the Mountain can be used to guide how we deliver information. Story patterns are often useful because they help the audience consume the presentation’s message. Whether a presentation is developed to inspire, inform or persuade, if the presentation does not connect with the audience then the time and effort for all parties are wasted.

9684430136_09e543796e_k.jpg

A good story makes information engaging

Presentations are the lingua franca of many . . . OK most corporate IT departments. Presentations are used for many purposes, such as to inspire, inform, persuade or some combination thereof. The problem is not that presentation are a common communication vehicle, but rather they are often misused. I recently attended a Chamber of Commerce meeting where I watched a presenter go through slide after slide full of bullet points, charts and graphs.  Trouble is, I can’t remember much of the presentation a week later. If he had approached the presentation as a story using one of common story structures and added specific vignettes, the presentation would have had a better chance at making an emotional connection and being memorable.

Story structures are tools to build a connection with an audience and aid absorption of the entire overall message. An example of a common story structure used to guide a presentation is called the “Mountain”. The Mountain begins with describing a current state, shows how challenges are overcome as the story moves away from the current state towards a conclusion which that satisfies a need. I often use this structure to describe a project or an organizational assessment.  Each step along the path can accompanied by relevant and powerful vignettes to highlight specific points and to increase the audience’s connection to the presentation.

The most basic goal of a presentation is for the audience to remember what was said. In a Wall Street Journal article, Cliff Atkinson, a communications consultant and author of Beyond Bullet Points, suggested that raw data is not as persuasive and memorable as many in business believe.  Mr. Atkinson suggests distilling what is important and wrapping it in an engaging story so it can be remembered. The Inc Magazine blog entry by Riley Gibson makes a similar point, suggesting that stories create interest and investment so that audiences can “hear” and accept what you are saying. Richard A Krueger in Using Stories in Evaluation (2010, pp. 404-405) stated, “Evidence suggests that people have an easier time remembering a story than recalling numerical data.” The story structure provides a container to hold the data and message that is at the heart of the presentation so people can remember. This similar to my son-in-law’s uncanny ability to remember movie lines. Supporting this thesis are any number of study guides prepared for students, such as the one published by the Michigan State University College of Osteopathic Medicine that suggests using a story (more emotive the better) to enhance long-term retention and recall.

As I was leaving the Chamber of Commerce meeting, I overheard someone say they were glad that at least there were appetizers before the presentation because they didn’t get the point of the presentation. The comment was harsh, but even I, the ultimate data geek, had a hard time remembering the punchline. Whether a presentation is developed to inspire, inform or persuade, if the presentation does not connect with the audience then the time and effort for all parties are wasted (even if the refreshments were good).

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.

What Is The Story?

What Is The Story?

Has a child dropped their beloved toy? Is this a display created by an out of control teddy bear collector?  Or is this teddy bear a dog’s toy? Every picture tells a story.  The question we need to answer is, what is the story?  This is a situation most change agents face every day.

Effective process change isn’t possible if we aren’t as objective possible.  Objectivity is needed  in order to reduce biased interpretations and we all have our own biases.  Validate the your observations before you react.  Conversation is critical to gaining context and understanding.  When you discover a new situation ask those involved to tell you their story, you will be amazed by what you learn.

Making up stories to fit a scenario might an amusing party game however jumping to conclusions without doing your homework can easily take you down a dead end  path.