User Stories, Scenarios & Use Cases

Distinguishing these terms from each other can be rather confusing. In an attempt to go back to the basics, Nadine Schaeffer explains in detail the benefits and the necessity of using realistic situations.

When designing and developing software and sites, I hear these three terms–user stories, scenarios and use cases–employed all the time, often interchangeably. While I am not intending to issue a didactic nomenclature smack-down, some definition and clarity can’t hurt. Most importantly, when people are working together on a project team and trying to create and agree to any of these three kinds of deliverables, consensus goes a long way.

In general, all three terms represent ways that application teams try to define and understand what the app will do from the user perspective. User stories, scenarios and use cases can therefore be understood as framing devices; they provide mechanisms to understand and plan technology development around the end user, instead of focusing on development and product features around the constraints of the business, the platform or the underlying development of languages and libraries.

The exact purpose and audience for each term varies. Scenarios are generally used by user research people to communicate with design teams. User stories are written largely by project/product managers as part of definition and requirements documentation. The audience for use cases is primarily developers who need to write test cases and need to understand if their data objects are handling the appropriate i/o, errors, and exceptions. Now let’s examine closely all three terms, associated deliverables and processes.

Scenarios

Let’s start with scenarios. They are usually tied to personas and are part of creating a story about who the user of a particular technology is, what they want, what they know. A scenario is therefore usually written in narrative form, perhaps with pictures and illustrations as well. Scenarios are generally written at the beginning of a project during discovery and requirement gathering phases.

They provide human-centered anchors to guide design and development by providing tangible faces, names and stories for how the technology will be used.

A common generic format for scenarios goes something like this:

User Stories

Now what about user stories? User stories are generally used by Agile development teams. They are meant to replace long complex documentation with short sentences that capture the essence of a user’s needs.

They are intentionally short and granular—each story captures just one task or action. User stories are defined during development before or at the beginning of each sprint.

User stories are generally written in this kind of syntax:

Use Cases

Finally, let’s describe use cases. Use cases are generally written as part of detailed product requirement documentation. They capture the goal of an action, the trigger event that starts a process, and then describe each step of the process including inputs, outputs, errors and exceptions. Use cases are often written in the form of an actor or user performing an action followed by the expected system response and alternative outcomes.

Use cases tend to employ this kind of format and content:

Still confused? Maybe a more tangible real

Still confused? Maybe a more tangible real-life example will help. . .

Scenario:

Josh is a 30 something mid-level manager for an ad agency, metro-sexual and beer aficionado. He likes to try new and exotic beers in trendy locations. He also enjoys using a variety of social apps on his smart phone. He reads a review on Yelp of a new burger & beer joint downtown with over 100 beers on tap, and decides to go walk over after work and check it out.

User Story:

A user must want to find a bar and drink a beer.

Use Case:

Customer walks to the restaurant

Customer enters the restaurant
Customer finds a seat at the bar

Customer scans the menu
Customer selects a beer
Customer orders selected beer
Bartender takes order
Bartender pours beer
Bartender delivers beer
User drinks beer
User pays for beer

In Summary

Use cases, stories and scenarios are not interchangeable terms–each defines a specific process and set of deliverables. That being said, there are no hard and fast rules. It makes sense to review the needs of your project, what stage of development you are in, the skills and familiarity levels of the team, and then choose the user and task definition process that will work best for you.

Links & More Info

Nadine Schaeffer

I am one of the owners and creative directors of the user experience design firm, Cloudforest Design. We craft outstanding interfaces for complex applications.
I have 20 years experience in the software world, focusing on building and leading teams to create usable and enjoyable user experiences. I have aided many companies large and small launch successful online web and application initiatives. In the past years, my work has focused on building successful user interface designs and flexible information architecture systems that integrate cloud technologies, responsive design across platforms and screen sizes, and community initiatives.

Nadine Schaeffer
I am one of the owners and creative directors of the user experience design firm, Cloudforest Design.

The Related Post

Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations ...
Testing in Agile Part 1 – INTRODUCTION TO AGILE In case you missed the first part of the series in our last magazine issue from Michael Hackett, Agile’s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.
When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them. “He who knows to unlearn, learns best.” — Anonymous The following are some of the key aspects ...
Armed with the right tool or set of tools, a development team can incorporate ALM into its Agile process and start reaping the benefits of Agile ALM. As the software development industry matures, it is devising methods for ushering products from inception to completion—a process that has come to be known by the buzzword ALM ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Four of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”   LogiGear Corporation  LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and ...
Team collaboration is essential for testing embedded systems. Developing software for an embedded system often carries more risk than for general purpose computers, so testing is extremely critical. However, there still has to be a good balance between time spent on testing and time spent on development to keep the project on track. As consultants ...
If your Agile implementation is not about people, you’ve missed the boat! The most profound impact to becoming more Agile is happier teams! Agile manifesto Value #1: * Individuals and interactions over processes and tools Words like these do not show up in Waterfall or RUP SDLC process descriptions. Agile cannot get more basic than ...
Author Jonathan Rasmusson explains in his latest book how to successfully set-up, execute and deliver Agile projects. Download the excerpt below for “Chapter 7: Estimation The Fine Art of Guessing.” To read his interview in last month’s issue, please click on “Spotlight Interview: Jonathan Rasmusson” to read his views on the best practices for test ...
This is part 1 of a 2-part series. The 1st part will discuss the culture and mindset around Agile, and how Agile Quadrants are used. Part 2 will discuss how to use the Agile Quadrant, the significance of Automation in Agile Quadrants and how to use Agile Quadrants to overcome Quality Assurance headaches. Organizations aspire ...
In the decade since the Agile Manifesto, the movement has encouraged a number of best practices like test-driven development, user-centered design, iterative development, clean code, refactoring, continuous integration, and—arguably—cloud computing. I’m a card-carrying Agile zealot, and to me its benefits are unarguable. Is your IT organization ready to be Agile, seriously? Score yourself on these ...
Agile, in terms of software development, has incorrectly and for too long come to mean fast and “getting product out the door quicker.” But Agile is not about speed; it is about being flexible. I always begin my discussions on Agile development by getting a definition for the word Agile. Agile, in terms of software development, ...
LogiGear Magazine – July 2013 – Agile Testing

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe