The Forgotten Agility of User Stories

Let me tell you a story.

Oops, that wasn’t a story. That was a template of Joseph Campbell’s Monomyth, which he and others claim is the basic template of a whole host of legends known the world over.

Sorry about that, let me try again. The story’s really good, I promise.

There, I filled in the blanks of my template. Now I have told a complete story.

Except it’s completely awful. That lifeless template just sucked the soul out of arguably one of the greatest works of Fantasy literature ever written.

Truly a powerful evil is at work here.

What a user story is

That template you just read is a zombie. It’s dead. It stinks. And it’s going to instantly turn whatever falls into its clutches into an equally ugly, lifeless shell of its past self, just like my version of The Lord of the Rings up there.

This isn’t how people tell stories.

Ask your friend to tell his story about that one night, the one where he told the bartender “give me six shots of the strongest thing you know how to make.”

Ask your other friend about when she was driving home at 4am falling asleep at the wheel then woke up smashing through a fence into an open field doing 80mph.

With tonal shifts in a storyteller’s voice, gesticulations as they make motions in the air illustrating action, pauses and eye contact with a crowd, storytelling is very much alive. It paints a picture in your mind’s eye so that everyone listening can take part in a shared mental experience.

Forget what you’ve heard about “user stories” being that zombie template with its little blanks filled in.

A user story is a story your team can tell about being a user of your product.

User stories are born in face-to-face conversations with each other as a product team. Business analysts, managers, engineers, designers — anyone on the team responsible for making a quality product gets together and talks about the product. You do it early, you do it often, and as a result you all understand the narrative of what it’s like to use your product.

Hey… individuals interacting rather than just a fill-in-the-blanks process? Collaboration over requirements documentation? Already sounding a bit more Agile.

Oh my god. By many measurements that is a well-written “user story.” I couldn’t write it without making a “Who farted?” face. It’s so mangled by the shackles of its own process that the sentence doesn’t even resemble natural English. No one would ever talk like this, and frankly, being forced to is dehumanizing.

Picture somebody telling you about this game idea they’ve come up with:

“So, I call it Snake, ok? It starts off and you’re controlling this short little line moving around the screen. It never stops moving and if it hits the edge you die, but you can steer it up, down, left, right. So you steer this line toward a little dot. And when you run into the dot the snake ‘eats’ it. The line grows a little bit longer, and there’s another dot over here now. So the snake keeps moving and the goal is, you know, you gotta eat as many of these dots as you can without running into your own body, and your body keeps getting longer and longer the more you eat.”

Can’t you see this person talking with their hands, drawing the imaginary snake game on the table with their fingers? Can’t you imagine this conversation taking place over coffee or dinner, far from the sterile conference room where you usually craft requirements?

This is a user story. It gets in your head. You can picture being a player of the game. You can tell someone else the story later.

For convenience, can you break that story down into a few sentences that each fit the “As a/I want/so that” template form? Absolutely. Are those single sentences the user stories? Is my paragraph at the start of this article The Lord of the Rings?

Absolutely not.

What a user story is not

A user story is not that template with its blanks filled in. That filled-in template is a prompt, a note card, something you can hold up to any member of your team to remind them of the story so they can tell it to someone else.

A user story is not a good way to state requirements. Why would it be? We’ve already established that no one talks like this:

“As a vegetarian patron of your restaurant I want a pizza with non-meat toppings like mushrooms, olives, and extra cheese so that I can feel welcome to enjoy a meat-free pizza that will fulfill my body’s natural need for sustenance.”

What is this product backlog item? It’s the ability to order vegetarian pizzas.

It’s great for everyone to know why a user would want this feature, but forcing your team to talk like this is a little crazy. Tell a story that describes the vegetarian customer’s ideal experience in your restaurant. Then let this little template act as a prompt to conjure up that story.

Agility is not a process

Folks who want to “do Agile” always seek the formula to follow.

The formulas are out there, too, like our old friend the user story template. And if that’s as far as you want to go, you can rest on the plateau of following an “Agile process.” It may be a little better than whatever you were doing before.

Those who embrace being Agile recognize the real task is simultaneously much simpler and more difficult than finding a new formula to apply. Like every “Agile” concept, the user story is a call to communicate as a team and to share a personally-invested vision of what you’re all building together. Accomplish that and the question of what format to write these stories in won’t just be answered; it won’t matter.

If you liked this, please recommend it. Responses and notes are always very welcome. Thank you to Jeff Patton, creator of User Story Mapping, who originally helped me to see user stories as, well, stories.

Theme not found. Dumping all thoughts.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store