Business Analysis Business Driven Soap Opera Testing stories

Where is the ‘story’ in user stories?

There’s an old Jerry Weinberg quote:

“no matter what the problem is, it’s always a people problem”

which pretty much describes every project I’ve worked on over the years. Lately, I’ve particularly noticed that most of the tough problems evident on projects are more people or business problems than technology problems, which makes me think it’s worthwhile for me to continue my exploration of the business/user end of my list of software development roles.

BA = Business Analyst
UX = User Experience
ET = Exploratory Tester
TT = Technical Tester
Dev = Software Developer

In this vein, I’ve recently been trying to understand how to better articulate user stories, in that one day I’d love to work as a business analyst.

Most nights I read stories to my (almost) three year-old son as a nice way to end the day. Lately I have been making up my own impromptu stories to keep things interesting. I have really enjoyed making up stories on the spot; I think I’d be a good BA.

But thinking about user stories along with bedtime stories immediately raises a question: where is the ‘story’ in user stories?

Most user stories at work sound something like this: “As a user, I want to log onto the system, so that I can access my information”. What a shitty story! Sorry, but seriously, if I told this story to my two year old son, he’d die of boredom!

I’ve spent a fair amount of time reading about user stories but I still can’t find out why they’re actually called stories, because I don’t think they are actual stories:

An account of imaginary or real people and events told for entertainment: “an adventure story”.

The closest thing I have found to actual user stories is the concept of ‘soap opera‘ testing scenarios which outline implausible yet possible scenarios:

“A man (Chris Patterson) and his wife (Chris Patterson) want to take their kids (from previous marriages, Chris Patterson, a boy, and Chris Patterson, a girl) on a flight from San Francisco to Glasgow to San Jose (Costa Rica) to San Jose (California) back to San Francisco. He searches for flights by schedule. He’s a Super-Elite-Premium frequent flyer, but he doesn’t want the upgrade that the system automatically grants him so that he can sit with his wife and kids in economy class. He requires a kosher meal, his wife is halal, the boy is a vegetarian, and the girl is allergic to wheat. He has four pieces of luggage per person (including two pairs of skis, three sets of golf clubs, two 120 lb. dogs, and three overweight suitcases), where his frequent flyer plan allows him (but only him) to take up to four checked items, but the others can only take two each. He gets to the last step on the payment page before he realizes that he has confused San Jose (California) for San Jose (Costa Rica), so the order of the itinerary is wrong. The airline cancels the flight after it has accepted his bags, and reroutes him on a partner. The partner cancels the flight (after it has accepted the bags) to San Jose (California) so it reroutes him to another competitor, who cancels the flight (after accepting the bags) to San Jose (Costa Rica) and reroutes him to another partner, who goes bankrupt after it has accepted the bags for the San Francisco flight.”

~ Michael Bolton

Now that’s a real user story!

So, I think we have two choices on the user stories front. We can either make our user stories actually like real juicy stories, or at least start calling them something else!

11 replies on “Where is the ‘story’ in user stories?”

With this attitude you’d make a terrible BA 😛
Also, if we should start calling stories something else, I vote we call em “instructions” (to Devs)

A story, pretty much by definition, includes such things as a setting, a sequence of events, and a conclusion. Something I too realized when making up stories for my daughter.

I have publicly stated these things should be called “User Statements.” I am fine with calling them statements. I am fine with using them as placeholders for conversations future and past. I just hate calling them stories. They’re not.

But there should be stories within a User Statement. I think all requirements should be behavior-based and written as stories. We should start with a known actor, understand the context, describe the particular sequence of events, and then the resulting system response(s).

Most people know this technique as Behavior Driven Development or BDD.

Hi Alistair,

My take on the “user stories” label is probably due to the timing of alternatives when they were created. Namely, “use cases” and “requirements specifications”. I can’t find much reference material on why they were labelled as user stories, but I believe they the name given to the tool to help “stakeholders explain their stories to the development team,” thus, opening up a conversation.

To me, this was a bridging tool to improve collaboration in environments and a way to anchor them as an alternative to “use cases” but without being a “hostile alternative”.

I think if you contrast it to the alternative, the encouraged practice could be considered “more of a story”.

Some references that I think are useful:,

I need to know what those parts are?
A start, a beginning and an end?
Or a plot, some characters and a setting?

I think what seems to be missing these days is the complete story. Often we confuse the “story card” on the wall for the entire story. This card is just the title or header for the story that you have accumulated and is the basis under which we have conversations around the story.

When I first started writing user stories, we use to write these long detailed narratives as part of the story. This was the elaboration of the idea that was written in more of a story format captured from the user or business owner.

A narrative is a constructive format (as a work of speech, writing, song, film, television, video
games, photography or theatre) that describes a sequence of non-fictional or fictional events.
The word derives from the Latin verb narrare, “to tell”, and is related to the adjective gnarus,
“knowing” or “skilled”.[1]

The word “story” may be used as a synonym of “narrative”. It can also be used to refer to the
sequence of events described in a narrative. A narrative can also be told by a character within a
larger narrative. An important part of narration is the narrative mode, the set of methods used to
communicate the narrative through a process narration (see also “Narrative Aesthetics” below).

Along with exposition, argumentation and description, narration, broadly defined, is one of four
rhetorical modes of discourse. More narrowly defined, it is the fiction-writing mode whereby the
narrator communicates directly to the reader.

From Wikipedia:

I think teams rush now to get to the development and often skip this step or make it very brief. Perhaps it doesn’t add real value any more and has evolved to extinction or has been eliminated as waste in the process. Maybe we have just lost some of our discipline and should revisit this practice with new eyes. Perhaps a conversation in your next retrospective is in order to challenge your teams to do it better.

Thanks Alister for making us think about this again.

Not to mention the “Actor” is always either “user” or “system” — neither of which describes an actor with a motive. The only exception is when people write stories that along the lines of “As a capitalist…I want to make money”

Leave a Reply

Your email address will not be published. Required fields are marked *