User Stories vs Real Stories

Lots of product teams use “User Stories“. They have a particular format, like this…

As a user, i want to search for products, so that i can quickly find what i want.

To any normal person, this may be called a “story” but it obviously isn’t a real story, a story that’s engaging. It’s missing three key ingredients…

1. Every story needs an ending

I think of the format “As a blah i want to blah so that blah” as Context, Desired Action, Desired Outcome. It sets the scene but that’s just the beginning of a story. What about the middle and the end?

The end is fairly simple, it’s the actual outcome. For example…

Adding a product search reduced the average time to find products from 10 seconds to 4 seconds. This increased revenue by 3%.

I’ve worked for lots of organisations and I’ve rarely seen this. When i have seen it it’s been very powerful . The Lean Startup movement talks about “outcomes over deliverables”, but this hasn’t hit the mainstream (compared to Scrum, for example).

NOTE: User stories are different to tasks.

2. Every story need a soul

Real stories have a protagonist and emotion.

“As a user” introduces a role.

“Mary is a customer on” introduces a protagonist. (This is a perfect excuse to use the customer personas that have been gathering dust on the shelf).

What if the beginning of the story even added an emotion…

“Mary is a customer on She’s frustrated because it takes her a long time to find the product she wants by navigating categories.

She wants to search for products, so that she can quickly find what she wants.”

Protagonist. Challenge (with emotion). Desired Action. Desired Outcome.

3. Every story needs a middle

Real stories are a journey. For a user, what’s the journey from “wants to search for products” to actually being able to do it?

It’s the journey of delivering the product search. It’s the conversations between developers, designers, users and testers involved in the process.

In 1998, Alistair Cockburn coined the phrase, “A user story is a promise for a conversation”, but the importance of having the conversations is lost on many teams.

3b. Acceptance criteria

The conversations are often summarised as acceptance criteria. For example…

Given the user is on the search results page
When they tap a product summary
Then the product details should be displayed

Could this be more engaging, like a real story?

Mary, a user, is on the eBay search results page. She taps a product summary and this displays the product details.

That might be more engaging, but for acceptance criteria i prefer simple over engaging.

Into the wild

I’m hoping to add these ingredients to one story and see if it has some practical value. How will a “real story” fare in the wild? Leave a comment below!

Categorized as Agile

Leave a Reply

%d bloggers like this: