Skip to main content

Development

Why Does Agile Call Its Requirements, User Stories?

First, a little bit of a personal story:

I grew up in a family of great storytellers:

  • My mom could bring alive comic characters with descriptions and add the sounds of them falling, crying or laughing.
  • My dad could lead you to the moon with his drawn maps and landmarks. He would even add details, such as the time taken to wait for traffic.
  • My late grandpa could engage people of all ages with stories about his personal experiences and I still remember his love for animals from the way he narrates the story “Androcles and the Lion”.
  • An aunt of mine would include moral stories and mathematical tables in children’s lullabies so that the kids would learn to know them as songs.
  • I can almost hear my late uncle narrating “The Blue Cross,” a classic short story by G.K. Chesterton, even now. He could capture the attention of the audience even while explaining some of the hypothetical concepts in Physics.
  • Another uncle would ask you the never-expected questions pertaining to a scenario so that I would learn to prepare for never-expected constraints too. A tough end-user to be satisfied.

Wow…my family makes me so proud and fortunately, the storytelling and narrative traditions are continuing to date and are passed on through generations.

Let’s extend the storytelling technique to the Agile world:

  1. Why do you think I was able to remember so much about these stories and narrative sessions?
  2. How many of you were reminded of your own experiences while reading through the above bullets?
  3. Why do you think we call the requirements User stories in Agile?
  4. What am I trying to project through this write-up?

Let’s answer the first 2 questions:

Human brains are wired to enjoy stories and comprehend the simple equations of cause and effects from the stories. The human brain actually makes up small stories for every conversation or action it is about to process.

Genetically, human brains are also experts in relative thinking. That’s why you may have been reminded of your family members while reading the above anecdotes. The human brain has perfected this relative thinking so much that the mention of a delicious food by your friend can make your mouth water (a biological response). That’s why we can feel the joy, sorrow, or pain by just listening to stories.

Why Does Agile Call Its Requirements, User Stories?:

  • The human brain thinks in stories.
  • Humans have evolved in communication, idea-sharing, and knowledge-sharing through storytelling and stories that are aware of the cause and effect on an audience.

Why are User Stories Easily Understood?:

An end user’s expectation of a product can also be understood better if it is structured as a story with a description of the expected audience (user), causes (reason) and effects (goal).

Thus, the basic user story structure evolved as follows:

As a < type of user >, I want < some goal > so that < some reason >

More details are added to the user story:

  • By splitting the user story into multiple, smaller user stories
  • By adding acceptance criteria

Epilogue:

Agile has aptly called its requirements “User stories,” the intention is metaphorical.

To me:

All products are dreams/wishes,

All requirements in the products are different (user) stories that different users want to hear from those dreams!

Great dreamers/visualizers (Product owners), Great story writers (BAs), Great stories (Complete requirements with acceptance criteria), Great story listeners (Developers, Testers) make a Great Agile team.

Thoughts on “Why Does Agile Call Its Requirements, User Stories?”

  1. It is really entertaining to read. This blog is both knowledgeable and nostalgic as well. Simple Amazing

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Gayathri Narayanan, SQA Manager

Have a hybrid background of engineering academics, technical writing and software process quality assurance for about 20+ years. Other than work, interested in art, writing, music.

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram