4 approaches to understanding user stories
Some time ago I talked to a product owner, who wondered that certain things had not been tested, although he had written all the information down, including a whole bunch of acceptance criteria. “And everything else that I have not written down is up to testers and developers to know anyway!” This felt like a flashback to old days. And no, I am not just talking about this, but it felt like a flashback to school. Maybe you remember scenes like this:
Classroom, circa 1992:
Teacher hands out a poem: “Take yourself 5 minutes to read”
I read the poem. It’s about a boy looking out of the window while it is raining.
Teacher: “What do you think it is about?”
Me: “About a boy looking outside of the window while it is raining.”
Teacher: “But what is it really about? What does it mean?”
Me: “…”
Girl in the front row: “I think it is about sadness. The whole mood is sad.”
History nerd: “And we know the author wrote it during the great depression.”
Me: “…”
Well, I guess you get the point, I wasn’t that good at interpreting poetry at school, even if I was kind of a history nerd. Now flash-forward:
University seminar, circa 2001:
Professor hands out a poem: “Take yourself 5 minutes to read”
I read the poem. It’s about a boy looking out of the window while it is raining.
Professor: “What do you think it is about?”
Me: “About a boy looking outside of the window while it is raining.”
Professor: “That is absolutely true from a text-oriented point of view.”
Well, I am still not very good at interpreting poetry, but what I took away from that course is that all kinds of text can be looked at from different points of view.
In general there are 4 groups of approaches to dealing with texts in a literary context and I feel that those can be helpful in reading user stories as well:
- Text-oriented approaches, which deal with the text as it is, with it’s parts (phrases, words, you name it) and it’s structure (hello grammar!).
- Author-oriented approaches, which deal with the text in combination with the biography of the author and it’s subconscious influence on the text.
- Reader-oriented approaches, which focus on the reception of the text.
- Context-oriented approaches, which try to put the text within a certain perspective.
If you want to know a bit more about certain approaches and ideas within these groups I recommend Klarer, Introduction to Literary Studies, 75-100.
Now, how does this help with user stories? When reading or writing user stories, we have to get away from a strict text-oriented approach. You simply can’t put every bit of information in a single user story and assume that everybody else understands it the same way. If that was the case the infamous “but that’s not what I meant” phrase would not exist (neglecting the mean/want/need debate here) and we could simply put all the information into one giant word-document (oh, that wishful thinking. Or is it irony?). Text-oriented approach have their value when thinking of rule adherence if you are using some kind of templates like “as x I want y in order to z” or your gherkin-scenario for acceptance criteria. But overall these approaches fade into the background of more suitable principles as 3C (card, conversation, confirmation).
Author-oriented approaches are in my experience a bit more important. Assuming that stories are written at approximately the same time as development will happen, we can safely neglect any historical aspects (well, at least on a grand scale that is). What we do have to keep in mind are the biography (see intro paragraph), especially if there might be several writers. Who wrote the story? Does the writer have special character traits? Does he have a certain writing style (some people just totally forget about user roles, because it is such an obvious thing for them or simply put all the relevant information in that tiny sub-clause written on the edge of the card)?
Reader-oriented approaches are about you, dear reader. What are your expectations of a user story? Do you expect all necessary information in that user story? Or can you simply assume certain things? “Oh, there is no specific user role provided, so I can safely assume that this applies for everybody. No browser mentioned? Well, I guess that means the same browser as always.” I would advise to be careful with these assumption. Some are certainly warranted (software is built with IE in mind, so I can safely assume that this certain feature will not be for firefox), but whenever in doubt, and probably sometimes when not in doubt, I would prefer conversation over assumption any day.
Context-driven approaches are all about context (surprise!). Things like political contexts are probably less important (although I would probably read a paper titled “The scrum team as 21st century soviet”), cultural studies and context may be of relevance, though (with all that offshore, onshore, nearshore, shireshore happening). And for everything else on context and testing, I will simply refer to AST and BBST.
In contrast to literary study it is not a case of choosing one approach (or picking your poison if you want), but of being aware of different approaches to the same text or user story. This will help you when either writing user stories or reading them. And it certainly has helped me raising questions from different points of view when talking about them. And that is probably the most important thing about it.
