Story Fomats
I've been on numerous Agile projects with varying methods for capturing stories. Quite popular (and purportedly the ThoughtWorks standard) is the "As a, I want, So that" story format.
While I have seen teams do well with this format, I think it can be radically improved with a minor change. I prefer to see "So that, as a, I want" story format.
My reasoning is quite simple; the emphasis is incorrect in the common story format.
Same words, different order
Compare these two statements:
As A Bank Teller, I Want a name search field, So That I can quickly look up customers.
So That I can quickly look up customers, As A Bank Teller, I Want a name search field.
These are arguably the same story. The words are precisely the same; merely in a different order. Pick them apart, word by word, and we all agree these requirements are identical.
Emphasis
But in planning meetings and even our regular work lives, we don't pick each statement apart word by word. Rather we take in the statement linearly, process it for meaning as we go, draw a conclusion of intent, and act.
Let me make it visibly clear what is happening in our minds as we process the two statements:
So that, as a, I want
"As a" is always secondary in our mental process. This is, of course, a generalization. If I am an account manager, I am highly attuned to all "As an Account Manager" stories. But on the whole, for whom is a clarifier, not a primary consideration.
With the common story format, our discussion is likely to be more around what the text field will look like, where it will be on the screen, and how it will function.
With the common story format, I often see stories devolve to the abbreviated, "As a, I want" form. This is quite dangerous. We are now delivering functionality that serves no expressed purpose.
Focus on Why (value)
By placing "So that" at the front of the statement, we've put an emphasis on why the story exists. If we can't say why we are implementing a feature, there is clearly no purpose for the feature. Even when we are certain that the purpose is obvious, it is best to include it. What is clear to the requestor may be opaque to the implementor.
Our discussions are now focused on value. We may spend no less time discussing specifics of the implementation, but we are first assured we know why we are delivering the story. Our implementation is better guided by why. We are free to explore alternatives that better suite the purpose.
Put purpose first; literally and figuratively
It helps to put the purpose of the story at the front of the story form. It places the proper emphasis on why and better frames our discussions. But if the purpose is inadequately stated, we are still likely to have the wrong discussions.
Take the time to genuinely consider the why of each story. What is the value to the business? How will the customer be able to confidently select this story over another in planning sessions? Consider using Vincent Partington's technique for creating clear stories.
Our original story is better stated as follows:
So That I can serve customers faster, As A Bank Teller, I Want an efficient way to look up customers.
We now express the actual value to our client and we do not mandate implementation in the story summary.