The user story metaphor – is it appropriate?

The user story metaphor – is it appropriate?
There is a significant difference between a real story and a user story.

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 a 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“
or
„an account, often spoken, of what happened to somebody or of how something happened“
or
„an account of past events or of how something has developed“
or
„a report in a newspaper, magazine or news broadcast“

OALD

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 the bigger picture

Let’s have a look at the agile manifesto and see how stories fit:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile Manifesto

Mike Cohn writes in what Martin Fowler calls the standard book on writing user stories (you can read my review of Cohns book here):

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.
And that’s where we started to go wrong. We shifted focus to a shared document and away from a shared understanding.

[Co10], p. 145f

Maybe the most important characteristic of an orally transmitted story is that it changes each time it is told. I have 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. 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.

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. And how do you call a feature-rich software? Storyful?

Conclusion

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. 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 highly doubtful.


References

[Co10] Cohn, Mike. 2010. User Stories Applied. Addison-Wesley. 15th edition.


You might also like the following articles:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er knappe sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen. Petre ist als Rezensent und Verfasser von Artikeln für nososo tätig.

Schreibe einen Kommentar