Whenever we teach/learn how to write user stories, we usually use the “As a… I want to… So that…” format, like so:

As a <persona>I want to <have a capability>So that <value this story brings>

It’s not uncommon we end up writing stories such as this one:

As the system
I want to remove duplicate entries from my address database tables
So that I don’t have duplicates

I hope that story has made you cringe. If it didn’t, what’s wrong with you?

Thinking about the Purpose of a User Story, let’s ask:

• How does the story above help the business either make or save money?
• Is “the system” a valid persona? (…maybe one day it will be, I guess…)
• Why is it important that addresses are stored in database tables (as opposed to documents or  CSV files)?
• What’s the problem with having duplicate addresses?
• How does that story bring value to the business?

What if we rewrite the user story in this manner:

As the marketing manager
I want to send direct mail with no duplicate addresses
So that I save on mailing costs of marketing initiatives

Much better:

• The story brings value to the business by saving on mailing costs;
• It makes it clear that the value is important to marketing managers;
• It indicates that sending direct mail for marketing initiatives is the business operation affected by the story;
• No technical details are specified;
• Any non-technical person can understand it.

With all that being said, here’s a question: what’s the single most important part or sentence in that story?

Here’s the answer: the “so that…” part. It is the part that tells us the purpose of the story. The why. It tells us how the story brings value to the business. It tells us why somebody is willing to pay money to see that story implemented.

Last But Not Least?

So, why is “so that…” the last part of the story?

Why build the suspense?

We shouldn’t expect anyone wanting to create cinematic versions of user stories, so let’s cut right to the chase and highlight the most important part of the story, by rearranging it like so:

In order to save on mailing costs of marketing initiatives
As the marketing manager
I want to send direct mail with no duplicate addresses

Right there, Start with Why. But first, let’s give credit where credit is due: I’ve first learned about changing user stories to go from “so that…” to “in order to…” on the Cucumber website. It made a lot of sense to me (it still does!) several years ago and I stuck with it.

That approach is so ingrained into my way of thinking that when I see a story written as “As a, I want to, So that”, I end up reading it backward (by reading the “so that” part first).

Why does it matter?

Over the years, I’ve sat in many meetings (Sprint Planning, backlog refinement/grooming, etc.), where the leader reads the story out loud following a pace that looks somewhat like this:

• “As a…”, spoken kind of fast, but the words can still be clearly heard;
• “I want to…”, spoken slowly, emphasizing the “want”
• “So that”, spoken fast, words hard to distinguish. More of a slur, really. That’s it: the person is slurring, not speaking.

But wait: if the “so that” is the most important part of the story, why are we slurring through it like that?!

There’s a lot of focus going into the want part, but not as much going into the why it’s wanted. In fact, I’ve seen a lot of time spent discussing “want this” and “want that”, and from little to almost no time spent on the why.

First Things First

My recommendation to people has been to start every user story with “In order to…”. If we don’t know how to finish that sentence than we don’t know what the value of the story is, and therefore, no time should be spent on anything else. Who the persona is (“as a…”) and what is wanted (“I want to…”) become irrelevant if the story lacks a strong why (“In order to…”).

In the example story above, after finishing the “In order to save on mailing costs of marketing initiatives” sentence, someone might raise a hand and say something like “I’m aware of a special service deal where we get significantly reduced shipping costs over X number of letters”.

At that point, the focus of the conversation could turn to figure out if there’s any chance that the cost to build and operate the new future would be more money-saving than the available service deal. Yes, software is NOT always the best solution, can you believe it?

Consider Adding Context to the Persona

I’d also recommend considering adding a context along with the persona in a user story, as described in this blog post. Take this contrived example:

In order to end my hunger
As a person
I want to get some food

Is the person really hungry for food? Maybe the person is just thirsty (the feeling of thirst and hunger can be very similar), so while the person may “want” some food, maybe what she “needs” is water. Adding some context to the persona would help clarify things:

In order to end my hunger and not get a stomachache
As a person who hasn’t eaten for 18 hours
I want to get some light food

Often, after adding context to the persona, we may end up seeing bits of information that should be added to the story in order to further clarify things, as it happened with the example above (chugging down a heavy meal after a period of 18 hours without eating probably wouldn’t be a good idea).

As a User?

And please, if the “As a…” part of a story reads “As a user”, take a step back and think a little harder about that; user is too generic of a persona!

A User Story should convey the value its implementation brings to the business. Value may directly or indirectly relate to money figures. Happy users lead to value.

It should always be clear if a user story helps the business either make or save money. But what about non-profit organizations? Simply replace “make money” with “make someone happy” and “save money” with “save someone from pain”. That’s value. You got the idea.

User Stories are placeholders for conversations. These conversations must be centered around value (not technology or implementation) and it should be approached from different angles, until both stakeholders and development teams are clear on the value.