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.

Copyright © 2004 Nat Pryce. Posted 2004-12-09. Share it.