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.

Advertisements