Refactoring User Stories

The current vogue means of specifying a story as popularized by Connextrix, Mike Cohn, Dan North is the form:

As a <WHO>, I can <WHAT> so that I can <WHY>.

This form has a number of benefits. It captures what the benefit of the story is, who benefits from it, and it does so in a simple, single sentence structure. It is written in the first person, which has some positive psychological effects on the reader of the card, in that it places the reader in the frame of mind of the WHO in question. All told, a strong format.

However.

I often find in practice that the format is actually written more like

"As a <WHO>, I can <WHAT> so that I can <ANY WHY THAT MAKES THE SENTENCE READ CORRECTLY WHILE AT THE SAME TIME APPEARING TO CONVEY VALUE>."

The GOAL of the story, the WHY, is reverse-engineered from the WHAT after the fact. This typically has one of two net effects. In the first case, the cards are accepted at face value, introducing the potential for both risk and waste into the system. In the second case, the development team is forced into a "root cause" search via "5 Whys" or some similar technique to validate that a smelly story in fact does contribute some value to the users who are subjected to it. This creates a source of tension between the development team and the customer, because the team is forced to question the customer. What we instead need to do is to place the goal before the feature and ensure that the sentence makes sense in that order. This has a remarkable effect on the quality of the stories.

Now, I struggle with the particular formulation. I have some simple goals in mind. I would like as much as possible to keep the good aspects of the earlier format, especially the psychological effects of using the first person.

As a <WHO>, I <WHY> By <WHAT>.

I am also fond of the following formulation, although it is not written in the first person.

To <WHY>, A <WHO> <WHAT>.

If you currently use the more popular story format, I would love for you to take a story or two, reform them in the two latter formulations, and post them as comments. I'll post some concrete examples as a follow-on to this post when it is not so late.

Comments

[Joshua]

I recently attended a key note presentation that you gave at Tulsa TechFest. You talked about a 'pull' system managing work load. Do you have any recommended websites, books or articles that I can read to learn more about that?

Thank you for a great key note!

[Chris Tullier]

Great idea