Scenarios, User Stories and Use Cases…Oh My!

At some point during a discussion of project deliverables, confusion will result due the similarity of scenarios: user’s stories and usage cases. Despite the similarity in name, each results in a different deliverable because each has a different intended audience. 

Scenarios are created by user researchers to help communicate with the design team.  User stories are created by project/product managers to define the requirements prior to a sprint in agile development. Use cases are created for developers to help with testing. The difference in target audience means that the structure and information contained in the three approaches also varies.

Scenarios are stories that capture the goals, motivations, and tasks of a persona in a given context.  A scenario will include pictures of the persona, the context, and anything else that contributes to the story. Scenarios are used to bring the persona to life so that designers can role play when making design decisions. An example of a scenario, minus the accompanying imagery, is shown below.

“Jim, a second year internal medicine intern at Mount Pleasant Hospital, walks into the room of his patient, Andrew Ross. Since Andrew stayed the night in the hospital, Jim needs to review Andrew’s medical records to see if the nurses on the night shift had checked in and recorded any changes in Andrew’s condition.”

Generated at the beginning of an agile sprint, user stories are brief statements regarding the requirements of the system. While the format varies on organizational/personal preferences, the traditional format for creating user stories uses the following statement; “As a <User Role>, I <<want/need>> <<goal/desire>> so that <<benefit>>.”  Use of “need” versus “want” indicates if a requirement is required or a “nice to have” when building the system.  An example of a user story is shown below.

As a doctor, I need to get up to medical date records so that I know how to proceed with my patients’ treatment

Use cases are a set of instructions for achieving a goal. The audience should be able to read each step in a user case and know what to do with the system and how it should respond.  Use cases will also include branching logic so that steps will be skipped depending on what actions the users performs. Use cases can be represented as a flow chart. To add to the confusion, there are also usage scenarios which typically only follow one sequence of steps in the use case, and the actor is assigned a name, like in a scenario. For example of a use case is shown below.

Use case: Review Records   

Actor: Doctor

Steps:

Doctor walks into room

Doctor sees patient in bed

Doctor identifies patient in bed

Doctor sees medical charts on foot of bed

Doctor gets medical charts from foot of bed

Doctor opens medical charts

Doctor reads medical charts

Doctor changes pages to continue reading

Doctor closes medical chart

In summary, the scenarios, user stories, and user cases are not the same thing though the people will try to use them interchangeably. While the context may help determine which of the three approaches is best (scenarios when dealing with researchers, stories in an agile environment, cases for developers), make sure everyone in a design sprint and project group understands the differences to avoid confusion around deliverables.