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.