Whatever happened to clear, consistent language? Why do we use words that have inconsistent meaning in contexts where they’ll be unfamiliar? Why, oh why?
Day in and day out I work with clients in an Agile development setting. I use words that have been trained into me, that I’ve been taught over and over again. But when I sit back and think about these words, they just don’t make sense. Let’s look at two of my favorite examples. First, some standard definitions:
Story – the plot or succession of incidents of a novel, poem, drama, etc.
Narrative – a story or account of events, experiences, or the like, whether true or fictitious.
Sounds pretty familiar, no?
Well in Agile these words take on a whole new meaning. A story is the encapsulation of some sort of requirement, based on a given user’s needs or wants. It generally takes the form of:
As a [user]
I’d like to [some action]
So that [resolution of need]
But wait, is that really a story?
A narrative is the document that describes this story in detail. Chock full of high level objectives, UI prototypes, test cases, and other minutae. If you asked a person on the street what a “narrative” is, there’s no way they would describe it this way.
So why do we insist on using these terms, with their off-the-mark definitions? I don’t know. They probably seemed all cutesy and different at the start, something that sounds fun and light when compared to heavier terms like REQUIREMENTS DEFINITION DOCUMENT. When it comes down to it, “Story” just sounds less beefy than “Requirement.”
Damn Agile, You Just Stole My Words
Aside from the simple misappropriation of terminology, I have a bigger issue with the use of these terms. In the Design world, “Story” and “Narrative” have real, relevant meanings that align with the standard definitions of these terms.
Both of these terms are used to describe, in detail, a user’s experience, either today or in some envisioned happy future. The Narrative is generally a more detailed version of the story, which includes a narrated scenario in the context of the tool’s use.
I might be splitting hairs, because I think the Agile use of these terms tries to get at the same thing…but they just don’t. An Agile Narrative generally doesn’t tell a real story in detail, it describes a requirement in detail. Likewise, an Agile Story describes a requirement, not a user’s journey.
In Conclusion
We have to be careful with the words we use. In the end, we’re all trying to build software that solve real human problems. Surrounding these problems is real human drama that can, if described well and designed for, be turned into happier situations. I believe the use of words with alternate definitions muddies the water, but certainly doesn’t get in the way on a day-to-day basis.
Whatever words we use, we have to be sure that our solutions fit into the contexts of our users. We must ensure that our software fits into our users’ everyday stories.
11 responses to “On the Misleading Lexicon of Agile Development”
I think “story” is a very good word and concept to use. It’s just that the “As a… i want… so that” is not actually a story.
A classic story arc starts with a person in some situation who is faced with a challenge, works out how to overcome that challenge and ends up in a new, better situation.
In a software project, a user performing some role in some context has difficulties that, with the help of the new system functionality, can be overcome, leaving them in a new, better situation.
The problem is not that Agile misuses the story concept but that the original concept of a story introduced in XP has been forgotten by the Agile community that sprung up in XP’s wake.
It would seem to me that this type of practice might be based on a line of reasoning that goes as follows:
– Computers are complicated things
– We’ve had some success at using metaphor-based interactions to make them seem slightly less complicated to the average person (in practice YMMV)
– Requirements documents for software are complicated
– If we use a metaphor-based method as the basis for coming up with requirements, maybe that will be easier as well.
In the XP world, aren’t stories explicity different from requirements?
Requirements are generally rigid whereas stories can be dynamic. Requirements can be met via one or more stories.
Use of story in the context of XP may not be ideal due to the previous definitions of the word, but requirement is not a suitable replacement.
Agreed with Nat.
“As a… I want… so that” is not the story. It’s perhaps the title and even that form is not necessary.
“Story” in an XP setting is what happens when a person talks to another person about how something is supposed to work.
“Narrative” is a non-standard term and you probably won’t find many people in the Agile community that will know what you mean.
I do think there is probably value in bringing in some of the UX concepts and terminology into the Agile community.
Note that “requirement” is poor given that many “requirements” aren’t actually required.
I remember on the bus at XP2000, someone (I think Alistair Cockburn) said that requirements are more like wishes to which I replied, “That would make Analysts, Wish Fairies”. 🙂
Agreed.At a large media company, we have to be careful to call “stories” as requirements something else because their definition of story is the content they publish in the papers and on their website.
Josh, which words would you use instead?
Liz – that’s a fair question. In general, it seems like stories in our context really mean “features,” so I’d just call them that. Perhaps narratives would translate to “feature details.” Then again, I generally gasp at the thought that software can simply be broken down to a set of features, but if that’s what we have to do to get them to a level where developers feel they can take a crack at building them, then I guess it works.
I don’t think agile has misappropriated “story” any more than design has 🙂
I’ll go along with everybody else and think that stories are quite a good term. Remember the title isn’t the story. It’s just a marker for the conversation you have with the customer to figure out what they want (see http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm).
Also, in my experience (and this may be due to my own UX bias) stories in XP bear quite a strong relation to stories in the usability sense. You don’t start off with the small-implementable chunks. You start off with the bigger narrative blocks, and these are split and thinned into the smaller story cards during things like XP’s planning game.
Think of the whole stack of story cards as the stories. I find that these are strikingly different from more normal “requirement” documents so the different name is completely justified. In fact what the XP planning game produces is something that looks very much like the results of a task analysis grid.
Jeff Patton has some good stuff on the topic. Check his blog .
Hi again Josh,
Some stories involve single features; other stories involve several changes across existing features. I tend to phrase the story narrative as:
As a
I want
So that
Those three lines form everything I understand as ‘narrative’; I may have misunderstood.
It’s the value that’s the focus of the story, rather than the feature. If we can deliver the same value with a simpler feature, we usually get (very enthusiastic) permission do so.
The story consists of a bunch of other things, too; the conversation itself, the scenarios / acceptance criteria associated with the story, an estimate, etc.
The piece of paper we write the story title and narrative on is a ‘story card’. It’s often the only bit of the story that everyone on the team gets to see, so it gets shortened to ‘story’. But the card isn’t the story; just a placeholder for it (not just for the conversation). And a story is definitely more than just a feature.
Does that make any sense? This is the way I think of stories, others may differ; but it meshes with (my) reality.
Oops, your comments take HTML – sorry! That should have been:
As a <role>
I want <a feature, some changes to features>
So that <I get some value>
Fully agree with this post. The term “user story” has been eating at me since its invention. And its gotten worse as User Story has become more stylized over the years. However, some good news … an increasing number of people are writing “concrete scenarios” a.k.a. real stories anyway. See http://alistair.cockburn.us/index.php/The_new_user_story_is_a_real_story (or in tiny URL: http://tinyurl.com/2b94qz).
Alistair