Write a Blockbuster Using User Scenarios

Big projects require many little user stories. But if these scenarios don't add up to one good story, then you're probably missing out on the big picture. In this week's column, Jeff Patton describes how his team weaves many small tales into a single strong report by identifying key characters and themes.

When developing user stories for new projects, I seem to run into the same problem. My team and I always start off strong. We put a lot of rigor into collaboratively arriving at a good set of user stories. Everyone feels pretty good about choosing the right stuff to build and the order in which to build it. But when we start building the story, it's hard to figure out how everything hangs together.

The Villain
As we start to build the functionality, the individual pieces look and work OK, but the software feels like "Frankenware"--lots of pieces stitched together into something that neither looks nor feels good. End users acknowledge that the software has all the features they prioritized as high, but there aren't enough features to do something useful with the software. This seems hard to believe, considering how long we've been adding features to the software, but sadly it's true. What we need is one big story that makes sense of all the little user stories.

The Hero
A user scenario was the big story we were looking for. It's a fairly simple; a narrative description of a person utilizing our software to successfully reach a goal. In the course of telling this story, the fictitious user (the hero) needs to leverage many of the features our software has in scope.

Let's look at an example. Say we're writing software for use in a retail environment. We're working on new order management software that allows customers to purchase items over the phone and pick them up later with the aid of a sales associate in the store. Some of our features in scope look like this:

  • Create open order
  • Identify customer and add to order
  • Add products to order
  • Add delivery information to order
  • Add applicable sales tax to order
  • Accept credit card payment over the phone

A user scenario of these features might go a bit like this:

John (our hero) works on the sales floor at Mega Electronics. Between helping customers in the store, he takes phone calls from customers asking for prices on specific items. John is paid on commission, so he wants to close every possible sale. If he can help the customers buy over the phone, that helps him, Mega Electronics, and maybe even the customers, since they may not need to visit the store to pick up their purchases. One of these business transactions might go as follows:

  1. During a short break handling walk-in traffic, John answers a holding phone call. A woman asks him if he's got a particular brand of sound-deadening earphones.
  2. John quickly looks up the earphones in the order entry system using the brand name and parts of the description. He tells her, "I've got two on hand."
  3. "How much are they?" she asks. John reads the price from the screen, "We have them at $169.95." "Ouch," she says, "that's more than I thought they'd be."
  4. John notices that on the screen near the description is a reference to recent good reviews and some prices from his competitors. He tells his customer about the reviews and lets her know his price is competitive. She says, "I'm rushing to get out of town and don't have time to shop around."
  5. "I can set them aside for you, or if it would help, ship them to where you're going," John offers.
  6. "Wow, that might be helpful. Could you ship them to my hotel?" asks the customer. John says, "No problem, let me get your details."
  7. John clicks a button to turn the headphones item into a new sales order.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.