I have been thinking again about what constitutes a good User Story.  In doing so I thought I would summarise a few of the main issues to consider.


A User Story is a short, simple description of the capability of a system told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template, and traditionally this was “As a [role], I want [a desire] so that [there is a benefit]“. Dan North has a good article on the principles.  Here is an example from his article.

As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed

This format was also famously presented in Kent Beck’s book User Stories Applied. More recently, attempts have been made at altering the structure of User Stories so that the business benefits are described first. We will see that in a second.

Behaviour-driven development (BDD) uses a story as the basic unit of functionality, and therefore of delivery. The acceptance criteria are an intrinsic part of the story – in effect they define the scope of its behaviour, and give us a shared definition of “done”. They are also used as the basis for estimation when we come to do our planning.

This all seems fine.  Nothing unreasonable here.  Or is there?  What if pulling the stories together to do the estimation might turn out to be a big piece of work in itself? Who approves that? And what happens if you don’t have the knowledge to produce the stories? What happens then?  Beck doesn’t offer any guidance.  The assumption is that you will never encounter this problem.  There are always people around that have the knowledge.   Sadly, this utopia isn’t always the case.

We also have the notion of a ‘Feature’. The IEEE describe a ‘Feature’ as a ‘characteristic that describes a software system’. I’ve no doubt there are other definitions that talk about business value, but lets just assume that the feature must be deemed worthwhile by someone.

Features != User Stories

A feature will encompass a number of User Stories.

As Matt Wynne brilliantly puts it, “User Stories are a great way to plan your work.  You can break down a big hairy requirement in to chunks that are small enough to work on without anyone freaking out”.

Having broken things down into chunks, we can pick and choose which ones to do first, and we may even find that some aren’t that important and could be dropped altogether. Our Feature might be

Specify delivery options for an order

and could give rise to this User Story. We have written it such that the benefit is described first:

In order to have my order delivered
As a customer
I want to specify my delivery preference

There are potentially many options and alternatives for arranging delivery. The analysis starts to suggest that there could be huge variations in the time and complexity involved in these options. So we split the story down:

One for standard delivery using royal mail:

In order to have my order delivered
As a customer
I want to specify standard delivery by Royal Mail

One for premium delivery where the user can specify a 2 hour delivery slot:

In order to have my order delivered at a specific time
As a customer
I want to specify premium delivery and choose a delivery slot for my order

Creating a system to handle 2 hour delivery slots is very much more complex than booking via Royal Mail. So we leave this until later.

We could break this down even further and add more user stories.  But we avoid the temptation to treat every User Story as a feature.  I’ve made this mistake myself.  Say we add a third User Story months later:

In order to have items within my order delivered in the fastest time
As a customer
I want to specify that my order can be broken into separate deliveries

What we don’t do is add an additional file for the new story and end up with a bunch of files like this:


The stories that make up the feature should all be added to a single feature file


which we enhance and add to*.

* This assumes you are using the Cucumber testing framework, but even if you are not, it is still good practice. And you may ask where Microsoft Word and Microsoft Excel fit in to all this – and the answer is nowhere. They are just flat files.

Feature Injection

As we said at the start, the traditional way of writing User Stories was to follow this structure:

"As a [role], I want [a desire] so that [there is a benefit]"

Later, there was a move towards a slightly different structure whereby the business benefit could be expressed more explicitly. Chris Matts devised a technique called Feature Injection which our examples above follow. The principle is that by moving the elements of the story around we can force people to think about the problem in order of the business value first, then the stakeholder value, then what the stakeholder thinks will deliver the value.


In order that PrintCo printer cartridge sales go up by growing the mailing list
As a PrintCo Customer
I want to be prompted for my e-mail address
So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty

As the analysis progresses, this might extend into:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
As a PrintCo Customer
I want to be prompted for my e-mail address
So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty

As a PrintCo Customer Services Rep
I need [something]
So that I increase the points I get for e-mail captures, improving my position on the high-scores display

As a PrintCo Customer Services Rep
I need [something]
So that I can see that the points I earn for e-mail captures affect my position on the high-scores display

I am not suggesting this is easy to do by the way.

A word about the scenarios

Having defined the User Stories, we then move on to define the scenarios. This is really a subject for another post, but I wanted to point a couple of things out specifically.

We write the scenarios in this form:

GIVEN (There we are in a certain situation or something has happend)
WHEN (I do something)
THEN (There is an outcome)

GIVEN-WHEN-THEN doesn’t imply there is a positive ‘benefit’ for the recipient or person carrying out the scenario. Also, it might come down to a question of viewpoint.  Not allowing something to happen, might be a  negative outcome for one role or user but a positive outcome for another.


Scenario 1: Account balance is negative
Given the account’s balance is below 0
And their is not a scheduled direct deposit that day
When the account owner attempts to withdraw money
Then the bank will deny it
And send the account owner a nasty letter.

Or we might have something like

Scenario: Deleting a facility house booking on an Order
Given an Order has been created
And the Order has been submitted for processing
And a line on the Order has been booked for a Facility House
When I navigate to the Facility House Booking
And I cancel the specific Booking
Then a booking cancellation is sent to the facility house

The issue with scenarios is that to uninitiated, it isn’t clear what is going on. How do you Create the order? How do you navigate to the facility house booking?

The BDD gurus will either say:

“It’s fine.  Look in the implementation code of the automated test”


“Ask your Business Analyst.  They will know”.

The problem is that if you live in the real world, its just not economic to automate everything.  And if you’re not able to, Given an Order has been created is a big deal because the steps involved in doing it might be very long and complicated and would somehow need to be included in the scenario. (Or if not, then documented by another means). I wrote about some of the issues around this previously here.  It is a topic I will return to, for sure…

« »