Stories
On a recent project we kicked off with a few meetings to extract requirements in the shape of user stories. We followed the widely used format of "As a... I want... So that...". During the meetings I found this format quite unsatisfactory - I couldn't get a feel for how the users worked, how the system that met these requirements would fit into their routine and how they would use the system to generate value. I think that by following this rigid format we lost a lot of communicative power that stories, in a more traditional sense, would give us.
Furthermore, the "As a... I want... So that..." format
makes it easy for users to slip technical details into the
requirements. The telling of a real story about their work and the
problems that they must surmount will hopefully help the
storyteller concentrate on the end result they want us to provide
and the business value that it will generate.
In the book
Story, Robert Mckee
describes how story tellers follow certain conventions to make a
story more compelling to the audience. Stories that follow these
conventions instil stronger reactions within the audience, and
transfer a deeper understanding between teller and audience, than
those that do not. I wonder if we can use some of these conventions
in describing software requirements to aid the communication
between users and developers. (Ironically, Story, a book that tells
people how to write, is itself written so badly as to be almost
unreadable).
Dave Snowden has done a lot of research into narrative and how it can be used for knowledge management. Dave gave a keynote speech and tutorial at XP Day 4, both of which generated a lot of interest among Agile developers. Several, including Rachel Davies, Willem van den Ende , Joseph Pelrine & Tim Bacon, have written about his talk so I won't summarise everything here.
One of the many interesting topics that Dave touched on was how people naturally turn to raw, personal stories rather than collated research when they want to learn how to solve a problem. Furthermore, people prefer negative stories that show what to avoid, rather than positive stories that describe best or good practices. This certainly struck a chord with me, as you probably could guess considering the theme of this blog.
Dave has built a "narrative database" that people can fill with stories and then search for insight into a situation or problem. The search criteria were particularly interesting: a user can specify the emotional intensity of the story, as well as on content. Perhaps a narrative database would be a useful tool for collecting user stories at the start of an agile project before pulling out or synthesising "archetypal" stories to act as system requirements. The emotional intensity of a story could be used to focus usability effort on particularly stressful tasks, for example.