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.
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:
- A card on which the story prompt is written
- A conversation in which users flesh out the
details of what is needed.
- A confirmation which the users need is confirmed.
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
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:
- User stories and the conversations provoked by them comprise
verbal communication, which is clearer than written communication.
- User stories represent a common language. They are
comprehensible to both users and developers.
- User stories are the right size for planning and
- User stories are ideal for iterative development,
which is the nature of most software development.
- User stories help establish priorities that make
sense to both users and developers
- The process enables transparency. Everyone
Cohn suggests six criteria of good user stories:
- Independent: each stories should ideally be
independent of the other stories, so as to facilitate prioritization.
- Negotiable: the stories are not contracts written
in stone. They form the basis of conversations, during which the story may be
adjusted, or even removed.
- Valuable to users or purchasers: sometimes the
purchaser may have different needs from the users. E.g. a company may have
requirements for consistency and cost-effectiveness that are of no interest to
the users of the software.
- Estimatable: it must be possible to estimate
roughly how much time and effort would be involved in fulfilling the story.
- Small: If the story is too big or too small, it
cannot be used for planning purposes.
- Testable: the story must be written in such a way
that it can be tested. For example, a story to the effect that “the user must
the software easy to use” cannot be tested, whereas “the user must get a
response within five seconds” can be tested.
Cohn’s book is interesting from a number of perspectives.
- The book catalogues the systematic use of stories by a
major 21st Century business sector, i.e. software
- 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
- The most useful stories are minimalist in form.
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
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.
In any event,
User Stories Applied
by Mike Cohn is well worth reading and belongs on the bookshelf
of anyone interested in the use of stories in organizations.