Telling the complete story

Decomposing the story format

Working with several clients, I see differing story formats. The format I see most recommended is "As a, I want, So that".  The format I see most utilized is "I want". Isn't this the important part of the story anyway?

I think not. Let's look at the three components: As a, I want, and So that.

As a

This tells us whom the story is for. If we've developed personas or identified our users in some other detailed capacity we probably have a sense of who this person is and what motivates them. If not, we probably have a vague sense of who this person is and are likely to assume they are much like ourselves.

I like personas. I like real people even better. But let's be honest; fabricated or real, these people are representative of a larger group. They are a generalization whose primary purpose is to help us understand what motivates the group. In other words, we get to know them so that we can empathize and better understand the problems they need solved.

I want

This tells us what we anticipate will address our need. If we've followed good usability practices or have done sufficient research we probably have a sense of how likely this is to solve the problem. If not, we probably have a vague sense that this is an appropriate solution and are likely to base the answer on what we've seen in other solutions.

I am a proponent of user centered design. The more we get users engaged, the better our solution. But the truth is, the "I want" is a guess that will only be proven once tested with real users, in our real application, in the real world.

So that

Ah, and here we are, at the crux of it. This is the problem we are trying to solve. The other two components of the story are supporting cast to this, the main character. Why is it that we tuck our star away at the end of the script? I do not know. I've previously suggested people change their story format to "So that, As a, I want" in order to focus more on the value and less on the means.

We frequently miss the point

I often see story cards that miss the mark in subtle ways. Consider the following:
"As an account manager, I want a listing of accounts, so that I can see them on the page."
"As a member of the support team, I want to track membership updates, so that I have a history of the changes."
"As a marketing manager, I want to enter testimonials, so that visitors can read them."

These stories adhere to the format, but they don't tell the complete story. We don't really know what business problem is being solved. Perhaps we can infer the problem, but there are likely to be vastly differing opinions. If we don't know what problem we are solving, we have no idea if the solution is valid.

A story that fails to tell us the problem misses the point.

Tell the complete story

Let's take a look at how these stories might read after a little more consideration given to the fundamental issue we are trying to resolve.

"As an account manager, I want a listing of accounts, so that I can quickly access any of my accounts."
"As a member of the support team, I want to track membership changes, so that I can identify potentially fraudulent accounts."
"As a marketing manager, I want to enter testimonials, so that prospects can see that we have satisfied customers."

These re-worked stories, while certainly not perfect, now tell us what problem we expect to solve. This gives us an opportunity to have a deeper discussion. Does the "I want" satisfactorily resolve the fundamental need described in the "So that"?

Given these final stories, I expect at least one team member would question the identified solutions. How many accounts does the average user have? Is a listing an appropriate way to access accounts? How would we identify fraudulent accounts? What data should we track and are there patterns we should monitor for in the code?

These discussions are good. They mean we are focused on the right things and we are thinking about delivering solutions, not features.


  1. The underlying motivation is the same, but I'm partial to the feature injection format of
    In order to
    As a
    I want to

    It is a subtle difference, but I find that focusing on the problem to solve before the persona helps me.

    Good post.

  2. Great post. I shared it with the rest of my coworkers and we've immediately started using the format.

    In our case the 'as a' first makes more sense, since we have lots of different types of users and potential customers and every new feature needs to be seen through that lens. However, on projects with less user types I can see how that might change. I think the important part is that the 'i want to' is never first. The 'I want to' is usually all we would see in a standard requirements document, but in most cases, the 'in order to' is actually what matters to them, and in some cases doesn't line up with what they think they want.

  3. It can be interesting to phrase the "As a..." and "So I can..." parts when what you're developing is a service to be invoked (or "consumed") by applications.

    "As a consuming application, I want to pull a current inventory, so I can, um..." Huh.