I have talked about the purpose of a user story and the idea of keeping stories straight to the point. I’ve recently run into a good example of how a user story could be improved, and I’ll share it here with you. The original story looked somewhat like this:

In order to quickly navigate through Sales Orders
As a salesperson working at my desk
I want to see a list of all existing Sales Orders
So that I can navigate to Sales Order that I need to take an action on quickly 

I get that the person wants to navigate through sales orders “quickly”. But why is that important? To get back to playing Candy Crush or scrolling through social networks?

In a conversation with the domain expert, I’ve learned that such a person takes calls from customers all day, so that’s why it’s important that the sales order lookup happens quickly; the business wants to take care of all of their customers, not letting them wait on the line for too long, and taking the necessary actions quickly.

With that clarification, let’s think of the following bit: “I want to see a list of all existing sales orders”. Does that mean “all existing sales orders on the entire database“? That could be a very long list!

After further clarification, the user really needs to see only a list of service orders for the customer who’s currently on the phone.

That information reveals some interesting bits:

1. The system only needs to present a limited list of results to the user (which certainly helps with the “make it quick” need);
2. We’ve learned a little more about the context to which this user story brings value: not only is the user “working at his or her desk“, but there’s a specific customer on the phone! That little gem tells us the one filter we can immediately apply to the search.

I’d then ask the following question next:

Does the user want to see all service orders for the given customer, or only the ones where the status is “open”, or “pending”, or “my goodness, this case really needs attention!”?

Maybe the answer is “well, most of the time the user needs to see the open orders, but having to see the pending ones also happen quite often. They almost never need to see the closed orders, though.” 

That last bit of information can help tremendously the effort of providing a good User Experience; the system can take that information into account and maybe preload all of the open orders for the customer, as soon as the user indicates which customer is on the phone (the system could even detect who the customer is by looking up the phone number in the database, if such info and integration are available).

With that understanding, maybe the user story could be rewritten like so:

In order to better assist a customer and quickly move on to the next customer
As a Salesperson taking a call working at my desk
I want to quickly see the customer’s Sales Orders, filtered to the “open” orders, and have easy access to the “pending” ones

Notice that the original story mentioned “So that I can navigate to a service order that I need to take an action on quickly“.  

What are the actions that this user may take given this context? The conversation about would certainly produce an entirely separate user story. Depending on the number and nature of the actions, it’d even be multiple user stories, one for each action.

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.