User Stories Applied

A book by Mike Cohn

Summary: User Stories Applied by Mike Cohn (Addison-Wesley. 2004) is an interesting book, which deserves a much wider audience than the software developers in Agile, Scrum and XP for whom the book is explicitly intended. Some interesting points that emerge:

The book catalogues the systematic use of stories by a major 21st Century business sector, i.e. software development.

In this sector, stories play a key role in organizational efficiency and effectiveness.

The value comes from the conversation that the story provokes, rather than the story itself.

Oral stories are more valuable than written stories.

The most useful stories are minimalist in form.

Review

How do you decide what software is meant to do? This is a surprisingly complicated problem. Many people are involved. Users want a useful system, but often they don’t know exactly what they want. And they don’t know what they don’t want until they see it. And they don’t always know what’s possible or how much it will cost. Programmers want to do interesting things with code. Product managers want flexibility combined with reliability. Testers want to measure. Project managers want a product that will sell in the marketplace but they also want it quickly and cheaply, and without sacrificing quality. Settling all these issues in a way that everyone can support, and maintaining that balance for months or even years, isn’t easy.

The traditional way of approaching the problem (the so-called “waterfall” approach) is by specifying an extensive list of upfront requirements, and then freezing those requirements for the duration of the project. In practice, this doesn’t work well. When you have one big decision, it inevitably gets some things wrong. That’s because it isn’t possible to predict the outcome of a big software project in advance. If users are given only one opportunity to say what they want, they will ask for more than they really want or need. Moreover they don’t know what they really want or don’t want in advance, and can’t see the implications of their requirements in terms of cost or time. As a result, upfront written requirements, once frozen, can themselves become the goal, when those requirements have ceased to represent what anyone really wants or needs. When tradeoffs are inevitably made between content and time, the choices don’t reflect real wants or needs.

In his very interesting book, User Stories Applied (Addison-Wesly, 2004) Mike Cohn describes a very different process in which user stories are employed to ascertain what the user really wants in a continuing conversation. There are a number of striking things about the book, which has wide application beyond the narrow field of Agile, Scrum and XP software development that Cohn explicitly addresses.

First, the story isn’t an end in itself. The story is a means to having a conversation. As a result, Cohn’s stories are minimalist in the extreme. An example of a “good” story is the following, written on a note card, about a software project involving the posting of jobs on a website:

"A user can find information about potential jobs by searching on the site."

There is plenty of space on the card for the developers to write notes about the story when the conversation is held.

An example of a “bad” user story, in Cohn’s view, would be one that spelt out a lot more details, like this:

"A user can view information about potential jobs by searching on the site, for salary, expertise, location, responsibilities, date the job was posted, name of the firm, and job title."

Cohn’s example of a “good” story card only just meet my minimalist definition of a story, namely an account of two or more events joined together by some kind of causal connection.  Some of his other examples of good stories cross the line and are not stories at all, because they only have a single event, e.g. “A user can post her resume to the website.”

Second, in Cohn’s view, stories are not intended to document user needs. Instead, stories are prompts for conversations in which programmers and users can figure out what is really wanted and then test and confirm that understanding with prototypes of what is needed. In fact each story is part of a three –step process:

Third, the stories are written by the users. That’s because the stories must be written in the language of business, not the language of computer programmers. The customer needs to be able to set priorities among different needs and so it must understand exactly what is meant by the story.

Fourth, the stories are imaginary, not true stories about things that actually happened. They involve the users imagining what it would be like, if the website was built.

Fifth, during a story workshop, users brainstorm as many stories as possible. The idea is to get as broad a picture as possible of the possible things that could be developed so that priorities can be established among the various needs.

Sixth, the stories are costed. Once they are out in the open, then the developers can start to figure out what it would take to fulfill each user story. The philosophy is that priorities can’t be established unless and until costs have been taken into account.

Seventh, once the stories have been costed, and the iteration period determined, then the stories are prioritized, i.e. they are put into piles according to their priority. The developers start working on the pile of highest priority.

Eighth, as the work proceeds, the users, or their representatives, stay in regular contact with the developers, and the stories are constantly adjusted; they may be changed or removed, or new stories added, as the work unfolds, and as the users perceive their needs in relation to the evolving product. Some stories may turn out to be harder than expected to fulfill and they may be moved to a later iteration. New stories reflecting new needs that become apparent in the course of the work.

Ninth, when the work is done, the stories are tested, i.e. they are put through a process of verifying that the stories work exactly the way the users expected them to work.

Among the reasons for using stories are:

Cohn suggests six criteria of good user stories:

Cohn’s book is interesting from a number of perspectives.

One fascinating question: could the practices described by Cohn be applied to other business sectors, such as my own business? Clearly, it could be applied to my current project of upgrading my website, which is iterative software development. My recent newsletter generated a considerable amount of additional traffic to the website, but no one (no, not one!) responded to my request for suggestions on things to improve on the website. Suppose I were to solicit user stories? Would that produce more of a response? Hint: send your user story to steve@stevedenning.com 

Could it be applied, for instance, to writing a book? The answer here is less obvious. A book isn’t usually produced in an iterative fashion, although I have made a practice of sending out early drafts of chapters to get feedback. The comments received have been useful but sometimes are entirely helpful, because they lack a grasp of the overall design of the book. This occurs because, naturally, they haven’t read the whole book at the time they are reading individual chapters. A book is about enabling a read to look at, and interact with, the world in a new and different way. It’s hard for readers to imagine this before they have read the whole book. Could reader involvement be made more useful by having readers share their stories using Cohn’s methodology, and then writing in a more iterative fashion, involving users at every step of the way? This is worth more thought.