So What's The Big Deal About User Stories? Part I

Part I–Why Do “Stories” Matter?
After my first long post on Grooming (No Bride, Just The Groom ), I have had a few off-line questions on User Stories and User Story Writing. (Even one from my son-in-law, all the way from Afghanistan! How cool is that?) User Stories are at the heart of our work, so I’m always happy to work with people on the process and the background. To that end, Here’s a little background.

Why in the world did the founders of the Agile movement decide to call the body of requirements that make up the central building block of work a “user story?” The answer becomes pretty obvious if we think about what stories have meant for civilization since we started telling them–cautionary tales, explanations for the way we understand things, clarifications of roles–they are the building blocks for civilization. To extend the connection, really good story tellers throughout history know how to pull the listener/reader in so that we are engaged. We end up in an intellectual and emotional conversation with the story itself asking questions like
“How does this relate to me?”
What is this story really telling me about?
“Why did the hero make THAT decision?”
“How in the heck is Brer Rabbit going to get out of this one?”

Aren’t these some of the same questions we ask with agile stories. . . well, except the one about Brer Rabbit?

Really, at their core, the purpose of agile user stories is to initiate a conversation. The only difference being that in Agile, the story starts out very brief, and we take that story and add the details as we get answers to the questions.

Once that conversation takes place, the acceptance criteria begin to get fleshed out. The product owner writing the story gets to know the kinds of questions the development/testing team has about the early version of the story. Likewise, the Development and testing members of the team get to discuss the nuances of the requirements that the product owner might have intended. All of these details are captured in the acceptance criteria, (and may even affect change in the original story itself–clarifying who the actor is, the true intended outcome, and why this story is important.

All of those things occur when a story is written correctly. However, some might ask, “Isn’t all this talking a waste of time? Wouldn’t a story, if written well enough, not require any conversation?” Here’s a counter to that argument. Think about how much time can be wasted on questions being emailed back and forth piecemeal—or even worse, think of the waste of just building something incorrectly. The written word can be terribly imprecise, English, even more so –even in the hands of a great writer. The story leads to the conversation, and the conversation is at the heart of Agile
Specifically—One of the principles of Agile itself addresses it this way: