User Stories reimagined

Since the concept of user stories was introduced it has been used (and misused) in so many ways. The stories were intended to replace formal requirements (that were, for practical reasons, not followed anyway) and use cases (that were way too cumbersome to write). A story is supposed to be a promise to have a conversation around the subject of the story, to eliminate misunderstandings through speech, not writing. This means that a user story can be very high-level and somewhat abstract, and the discussion around it will make it more tangible.

Mike Cohn wished to formalize the user story a few years back. Having a common format helps the stakeholders to prioritize compared to having a lot of different ways to write similar feature requests. His suggestion of a format is now de facto standard:

As a [role] I want [feature] so that [benefit]

To explain something with the focus on who wants it helps the person reading the story to put herself in the shoes of this person. Mike Cohn tells a story about Beatles popularity during the sixties. Beatles were among the first ones using pronouns in the songs, such as She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. This helped people identify with the song text and thus get more into the music.

But, since it requires a little bit more thinking (and hopefully research) to find out who is wanting this feature and why, the story has been shortened to:

As a user I want [feature]

This will of course not help the person reading the story identify herself with the target group of the feature. And, not knowing the benefit will not help the story getting prioritized. The other day I saw a story saying As a database server, I want to be quicker and of course, nobody wants to identify with a database server. I hope the author of that story had had enough of these bad stories and was being sarcastic.

As a UX professional, I work more with target groups (often in the form of personas) and why these target groups need a feature, than with the feature itself. This will ensure that we only build the features that makes sense building from a target groups perspective, thus helping us building something that people actually want. A good approach is to use impact mapping (spoken about here, under the name of effect mapping), where you first find out the impact (or benefit) that the product you are building is supposed to make, for example earn more money to the company. Then you find out who can help you with this, the target group (for instance formulated as a persona) and in what way (their usage goal) a feature would benefit them in a way so that the product can reach its intended impact. These impacts, target groups and goals can add to the story structure like this:

As a [persona / target group]
I want [feature]
So that [benefit for the user (preferably measurable)]
In order to [impact / benefit for the company (preferably measurable)]

Now you ask yourself, since the main user of a user story is a developer, why would she need to know the impacts and benefits. The answer is simple. If a developer understands why a story is being made, it is easier to decide on a solution and it is way more fun to work knowing that you do something good for someone.

Here’s a more practical example of the format above:

As Kent the Single-Parent
I want to always be able to lock the door from the bed
So that I feel secure in the hotel room
In order for the hotel to be able to target more customer types

Now, the conversation will start. This conversation is between the product owners and developers as a minimum. User experience people and domain experts may come in handy to weed out the misunderstandings (see the article about roles). The findings are formulated in short scenarios, borrowed from specification-by-example[2] (a very similar method is called Behavior Driven Design) notation:

Scenario 1: [name / short description]
Given [the preconditions]
When [action is taken]
Then [consequences occur]

If we add a scenario to the example above and add measurable impacts and goals, it could look like this:

Feature: Remote locking of door

As Kent the Single-Parent
I want to always be able to lock the door from the bed
So that I feel secure in the hotel room
(7 out of 10 customers should rate the hotel room security above 5 on a scale from 1 to 7)
In order for the hotel to be able to target more customer types
(200 more customers per month)

Scenario 1: Lock switch function
Given there is a bedstand with a switch
When I switch on
Then the door is locked

The scenarios can easily be used for both BDD-programming, for instance with SpecFlow, and as a base for quality assurance. The story cards that you would put on your wall would consist of the first part, not the scenarios.

For the kind of stories that do not have a clear target group, like the As a database server-story above, we add another user story type called Chore. The format is the following:

[Feature/Chore] is needed / required
So that [impact / benefit for the company (preferably measurable)]

Scenario 1: [name / short description]
Given [the preconditions]
When [action is taken]
Then [consequences occur]

Adding the So that-clause to the Chore gives the possibility for a more technical story to be on equal terms with a user story when it comes to prioritization. Otherwise, a developer could have a way harder time to convince a product owner that a certain action taken would be a very good idea.

As I said, these stories exist as a promise for a conversation, a conversation that will lead to great communication. And that is the impact that we want.

Addendum

The principles of LeanUX phrase user stories as hypotheses to force validation as soon as possible. Shorter and shorter feedback loops are better for knowing you are always building something valuable. A LeanUX user story combined with the baseline above could look like this:

We assume that

As Kent the Single-Parent
I want to always be able to lock the door from the bed
So that I feel secure in the hotel room
In order for the hotel to be able to target more customer types

We intend to prove this hypothesis by
Showing that 7 out of 10 customers rate the hotel room security above 5 on a scale from 1 to 7
Reaching more than 200 additional customers per month before the end of the year