Before agile we had requirements and use cases and scenarios. They were pretty successful but in the end they’ve been found wanting. User stories followed. They are a reminder that a more detailed conversation has to take place, they are the conversation and they are the acceptance tests as we find out in Cohns book on user stories ([Co10], p. 4). Stories and acceptance tests, what a strange conflation of words.
The Oxford Advanced Learner’s Dictionaries (OALD) defines a story (among others) as:
„a description of events and people that the writer or speaker has invented in order to entertain people“OALD
„an account, often spoken, of what happened to somebody or of how something happened“
„an account of past events or of how something has developed“
„a report in a newspaper, magazine or news broadcast“
None of them seems to give a hint of what a user story means: neither are user stories invented stuff for our entertainment (although I’ve seen some funny ones), nor are they some set of events that happened to somebody. And don’t get me started on epics.
According to the OALD, an epic is: „a long poem about the actions of great men and women or about a nation’s history; this style of poetry.“ Huh?
The user story and a glimpse of the bigger picture
Let’s have a look at the values proclaimed by the Manifesto for Agile Software Development:
Individuals and interactions over processes and toolsManifesto for Agile Software Development
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Keep these in mind. In a second we’ll see how stories fit the Manifesto’s requirements.
Humans used to have such a marvelous oral tradition; myths and history were passed orally from one generation to the next. Until an Athenian ruler started writing down Homer’s „The Iliad“ so that it would not be forgotten, stories like Homer’s were told, not read. Our memories must have been a lot better back then and must have started to fade sometime in the 1970s because by then we could no longer remember even short statements like „The system shall prompt the user for a login name and password.“ So, we started writing them down.[Co10], p. 145f – quotation marks added for Homer’s book, italics in original
And that’s where we started to go wrong. We shifted focus to a shared document and away from a shared understanding.
Maybe the most important characteristic of an orally transmitted story is that it changes each time it is told. This makes stories indeed „marvelous“. I own a 250 pages thick book comprising the same ballad which was transmitted orally for a very long time until various people decided during Romanticism to write it down. The book totals 50 different versions of the same ballad. In this respect an orally transmitted story is a wonderful metaphor for a requirement in the agile sense:
- Stories require interaction, there is one person that recounts and one that listens. The story teller generally has the desire of being understood, as the customer has the desire to get the product he wants and needs.
- The listener must have the ability to emerge in the imaginary world of the narration just like a developer or his representative must have the ability of understanding the customer’s domain and jargon.
- Stories can change each time they are told. Each relator might have his own version.
- The oral tradition is a collaborative effort of generations of taletellers just as a piece of software is a collaborative effort between customers and developers.
But software is no story
The behavior of software is predefined. Fixed. Consistent. Or else there is a bug. And tests are employed to check the behavior. End of story.
You cannot build software on „stories“, at least not on the fuzzy, changing ones from the oral tradition. (As a matter of fact you can, but it’s frustrating and inefficient.) And this is why stories have to be written down and have to be complete before starting an iteration. They must make the transition from a story to the fixed and consistent state of a requirement collection in order to start working on them.
And this is why Cohn errs. It is because of the shared understanding that we need to write things down, stories are just too volatile to build on them (well, it’s rather the human memory, which is not that precise). The debate is rather on how much is to be documented, how much is enough for a given project. But this is not really our topic here.
Consider the following two requirements:
Traditional: The system shall do stuff.
Story-style: As a user I can do stuff, so that I’m happy.
The essence is the same, it’s just the emphasis on the actor which differs. It’s the framing and of course this is what all this is about. While the “user story” metaphor works halfway for the initial stage of a requirement or as a “reminder” I find it completely inappropriate for its final stage when it has to be complete and consistent (which a „traditional“ requirement is expected to be). And how do you call a feature-rich software? Storyful?
Maybe user stories aim too high or they were just migrated to an environment much too different from the initial one (extreme programming). Extreme programming is a development method for situations with great uncertainties, small teams and on-site customers. Software which is born out of a close relationship between customer and developer can work with reminders. A developer can build upon the customer’s stories (it might become difficult though to pass on the knowledge when a developer leaves the company). But in a much more formalized Scrum context where as a developer your contact to the outside world is a product owner the benefit of the story metaphor is, in my opinion, highly doubtful.
[Co10] Cohn, Mike. 2010. User Stories Applied. Addison-Wesley. 15th edition.
You might also like the following articles: