Recently, I’ve been asked to work on a high-profile but very short-term project in my job. Other colleagues have also been pulled in at short notice to help. The project in theory makes use of user stories.

One colleague who was pulled in to help asked what a “user story” is. Others of us had been using the term as it was obvious but, taken literally, it isn’t. I tried to explain but found that the simplicity of the idea made it difficult to convey.

Although the idea is more straightforward than the specialist term suggests, its usefulness – and the implications of using that idea – make it hard to convey.

What is a user story?

A user story, simply put, is a concise way of representing a single requirement of a customer or user.

A user story can (should, even) literally be as simple as:

The user of this website can search for any course they want to study.

The details come later. The example above is pertinent to the project I mentioned earlier where we have been considering what a university’s webpages might convey.

It is important not to be misled by the term “story”. The “stories” themselves remain short and several stories can then be compiled based on customer needs to allow for a flexible approach to testing and development.

How does this help?

The “user stories” approach forms an alternative to more rigid project management methods where requirements can be lost in a mass of details. I’m thinking particularly here of badly written scoping documents I’ve seen in the past which have been too dependent on free-form prose and prone to “scope creep”.

The technique is part of an area dedicated to considering such factors in designing or developing a product. The area is called “user experience” (or UX). UX is particularly useful in software development, where all too often the needs of the end-user can be forgotten or neglected by those necessarily looking at the development from a technical perspective.

The webcomic xkcd used a Venn diagram to illustrate the difference expectations and needs of users of a website as opposed to its designers.

User stories fit well into the overall Agile and SCRUM project management methodologies for software development and potentially other areas too.

How does this work in practice?

Ron Jeffries summarises the aspects of a user story neatly in the subtitle of his book Essential XP, where the XP stands for Extreme Programming. The subtitle consists of the words:

  • Card
  • Conversation
  • Confirmation

Rachel Davies, in her 2001 article “The Power of Stories”, summarises the first of these aspects well, when she says that cards “represent customer requirements rather than document them”. That is to say that, in using the “user stories” approach, a story should be short enough to fit onto the back of a cue card. Its purpose is to focus the developers on the reason for developing a feature, which is why the detail should remain scant.

Having said that, the back of the card can feature further details, assuming they take the form of tests for a developer to run. These details emerge from conversation with the customer(s), whose more specific requirements must be distilled down into a series of points that can be used by the development or testing team. For example, a conversation with the customer(s) might yield the following points:

  • The user should be able to search for a course by title.
  • The user should be able to search for a course by entry requirements.
  • The user should be able to search for a course by lecturer.

These points can be shortened and translated for points the developer(s) or tester(s) should bear in mind, like so:

  • Try searching for a course by title.
  • Try searching for a course by entry requirements.
  • Try searching for a course by lecturer.

Put these on the back of the user story card and tick them off if and when development finishes. Assuming that all the customer points have been captured and successfully translated, once they are all ticked off the feature is ready. The testing stage is the final aspect of the story, referred to above as the “conversation”.

How does one write a user story?

Having said all that, writing a user story can be difficult. There is a conventional idea of length, but how should specific should a user story be, without going into detail?

The tests mentioned above could surely each be a story in their own right. The point of the “user stories” approach is to keep the customer in mind and this happens through conversation with the customer and with the developer(s). If the developer(s) indicate that a story is too ambitious in its scope then it should be broken down into smaller stories and this can be checked with the customer.

Mike Cohn in his book User Stories Applied: For Agile Software Development describes stories that turn out to be too broad in scope as “epics”. He even suggests that “epics” can be written deliberately, as placeholder cards whilst higher priority stories are developed.

To continue with the example above, we might decide that “The user of this website should be able to search for a course” is in fact too epic in scope and that the tests we listed suggest different features of the proposed website. If that’s the case, the tests can be rewritten as stories in their own right, to be developed as separate features with different levels of priority.

Once treated as separate stories, finer tests may emerge in conversation with the customer. Take the newly separate story “The user of this website should be able to search for a course by title”. Conversation with the customer might lead to further investigation of customer or user expectations:

  • The user should be able to search for part of a title.
  • If the user searches without entering any text, then all courses are listed.
  • The user should be able to find related courses without typing a word which appears in the actual title of the course.

And so on. These can then be translated into tests:

  • Try searching for part of a title to find a course.
  • Try listing all courses by searching without entering any text.
  • Try finding a course by entering a word related to the title.

The point is that the focus is always kept on the user’s requirements.

What next?

There are undoutedly flaws and problems with this approach, though I’m interested in exploring them further. One immediate issue I see with having tried this recently is the thought and time that writing good user stories requires. One has to bear this in mind as an overhead in a project and decide whether the approach is appropriate.

I’m personally interested to know if and how user stories (like the examples outlined above) could be created more efficiently and automatically translated into tests that then form part of a suite. Also missing from this outline is the concept of personae, i.e. descriptions of who “the user” is, another complicated aspect of considering user experience.

Generally though, I’m going to continue exploring using user stories in a number of different contexts to see how useful they are.