User stories are a way of capturing requirements for a product to be developed. It's most frequently used in software development, but there's no particular reason why any product could be developed using user stories; a refrigerator, a car, or a building could, in theory, use user stories for the requirement capturing phase.

In software development, user stories are often used in conjuncture with agile methodologies (such as Scrum), and certain computer programming techniques (such as extreme programming / XP)

A user story is meant to be an informal, human-readable, easy to understand statement, which can be used to prioritise the requirement against other requirements, estimate the effort required to implement the story, etc.

It sounds surprisingly low-tech, but one of the best ways of running user story workshops is to use index cards, and coloured felt-tip pens. Using thick pens means that the cards are readable from a distance, and it forces you to write fewer words on the cards.

The anatomy of a user story

There is no hard-and-fast rule for how a user story should be written, but it is useful if it is unambiguous, and useful both to the developers who will be implementing the functionality, and the people who are involved with the project management side of the project.

In the projects I have been working with, user stories contain the the following:

A title - this should be a 4-5 word title which makes it easier to refer to a particular story.

The user - We need to identify who will benefit from this particular story

The action - what does this story actually do?

The benefit - why do we need this story? What is the benefit?

Finally, some choose to include user acceptance criteria (on my projects, we put them on the back of the card, but YMMV), which allows us to check whether the stories have been implemented to our satisfaction.

Example user stories

Spell check - As a noder, I want my nodes to be spell-checked before I submit them, because that's less of a hassle than having to check them in a separate piece of software

Flagging content - As a blog visitor, I want to be able to flag offensive or incorrect content to help improve the site I am visiting

iPhone version - As an iPhone-toting user, I would like the website to automatically detect that I'm using an iPhone, and serve me a special version of the site which looks good on my iPhone, because this particular website would benefit from being easily available on the move.

Criteria for a good user story

Good user stories have quite a few characteristics, which can be remembered by the INVEST mnemonic.

I - Independent

One of the beauties of using index cards is that it's possible to move stories around on a surface easily. This is useful because doing so allows you to re-prioritise a project very quickly. This becomes complicated when user stories have interdependencies - if you were to have a user story for 'flagging inappropriate comments', for example, and another one for 'comment moderation infrastructure', you may find yourself with a problem: Implementing flagging first (which is a user action - see above) is perfectly fine, but if there's nothing the site admins can do with flagged comments, the first one is a waste.

Invariably, there will be user stories that are improvements on already implemented functionality, but the ideal way of doing this would be to write out the ideal functionality ('As a noder, I want full WYSIWYG editing with built-in dictionaries for UK and US English'), but then split out stories into different elements.

N - Negotiable

It's important that a user story remains negotiable - nothing is set in stone, and everything needs to continue being up for negotiation. When a card is written, it needs to be allowed to continue being changeable, in case new or better ideas come along. As long as the story card captures the essence of what is trying to be happen, the rest becomes free.

V - Valuable

Unless a user story adds value to the end user - why the hell are we even considering it? You'd be surprised how often people come up with wild dingbat ideas which actually have no benefit to the end user at all.

An example: 'As an administrator, I want a very elegant way of uploading images to my blog' has no value to end-users, unless it allows the admins to upload photos faster than any other way - and even then, you'd have to have a pretty strong business case to spend a lot of time on something as basic as image-upload.

E - Estimatable

If a story cannot be estimated (though, for example, planning poker), it isn't a good story - this is especially a problem because a story not being estimatable would mean it cannot be prioritised properly, which means that the stories can't be planned into the product backlog, which means they'll never make it into the project.

S - Sized appropriately

Some 'INVEST' mnemonics include the S as 'small', but it doesn't really make any difference - the size of a story is closely related to the 'independent' and 'estimatable', and basically means that big stories are too clunky to work with.

The example of 'As a noder, I want full WYSIWYG editing with built-in dictionaries for UK and US English', for example, could be split into 3: "As a noder, I want a way of adding content to Everything2", "As a noder, I want to use a WYSWYG editor to add my content" and "As a noder, I want a spell checker available when I'm noding".

On the other hand, it's appropriate for a some stories to be very big - which makes it an epic. This can be done when you know you want a certain piece of functionality in your software, but you also know that it is of low priority. Examples of Epics could be "E2 Facebook App" or "News aggregator" - both these stories are likely to have a whole series of sub-stories, but they wouldn't necessarily be needed to be split into tons of smaller stories until they need to be planned into a development iteration.

Obviously, in this case, you'd need the first story first - if there is no way of adding content in the first place, there's no point in adding a dictionary or a more advanced editor. However, the two second stories are independent - it's irrelevant whether you get an advanced editor or a spell-checker first, and this choice becomes the choice of whoever is prioritising the project.

T - Testable

Some stories are inherently testable, and it's easy to do so. "PDF export", for example, is a complicated story which is easy to test. On the other hand, there are other stories which are a lot more difficult to test, but more importantly, they might be deceptively difficult to test. If a particular story seems to fall into that particular category, the easiest way around it is to, well, write up the tests.

Of course, if you're doing test-driven development, this point is moot, and the 't' would be your starting point anyway.