It was on February, 2001, when seventeen practitioners formed what was called The Agile Manifesto. It seems that since then, we started to hear of the term User Story, although, as will be shown below, it seems that the term appeared before that date.

The questions that may pop-up on someone’s head are, is the User Story just a fancy name for the user requirement? Or, it is actually a new mindset of thinking in the way of dealing with user requirements?

Referring to Wikipedia about the history of user stories, I found that user stories originated with Extreme Programming (XP), but, it wasn’t until 2001, when Ron Jeffries proposed the Three C’s formula: Card, Conversion, Confirmation, where the components of the user stories were captured.

But, what are User Stories after all?

I really liked how Mike Cohn described User Stories, when he said:

User Stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

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

User Stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Before moving ahead, and comparing User Stories with Software Requirements Specifications (SRS), let us see how SRS is defined. Based on Chambers, SRS describes the essential behavior of a software product from a user’s point of view, where the purpose of SRS is to be a basis for agreement between the customers and the suppliers on what the software product is to do; a basis for developing the software design; a basis for estimating costs and schedules; a baseline for validation and verification; reducing the development effort; facilitating transfer; and serves as a basis for enhancement.

After knowing what they mean, how can we compare User Stories with SRS? I saw that rather than bringing theory to this part, why not monitor some discussions related to this issue? I thus went through some discussions at a Programmers Stack Exchange thread, and came up with the following:

One of the people involved in the discussion mentioned: To be honest, after spending close to two years immersed in Agile development, I still think “User Story” is just a fancy term for “functional requirement”. That person continues:What User Stories almost never capture, in my experience, are non-functional requirements like performance and security. These kinds of requirements are very difficult to write properly and the format of the User Story simply isn’t very good for capturing them, because they’re more about general product quality and mitigating (but not eliminating) risks rather than meeting a specific user’s need. So, I really think of User Stories as a subset of requirements, with a specific formula, and still use the terms pretty much interchangeably. The one major advantage User Stories do have over requirements is that the word “requirement” suggests that a feature is required where it is often just desired. User Stories can in theory be prioritized and slotted in for any release, whereas requirements appear to be a prerequisite for every release.

Other opinions arise mentioning that SRS focuses on “how” the user interacts with the system, and “how” to implement the functionality. On the other hand, User Stories focus on “what” (interaction between user and system) purpose do features have, such that, the task of a User Story would be a functional requirement, and is the expected work product after the functional tasks have all been completed. Thus, they are completely different things.

Requirements assume that the design of the application is done beforehand, and development is considering the implementation of that design.

User Stories insist that the design of the product is done at the last minute, and is a collaboration between a product person and a developer person, and the details are decided during implementation.

So, as can be noticed, the amount of details provided is different using the two approaches, such that, in the User Story for instance, there is a lot of information that is available not available in the requirement, namely, what is we are trying to achieve with the feature.

Others go and mention that a functional requirement is a formal specification that allows one to know exactly if the software works or not. Whilst a User Story is aninformal way to describe a need of one of the User Stories, such that, it doesn’t specify a rigid specification to determine if the software is valid or invalid. Although you can test some part of the User Story, its real completion is when the user says : “Yes, this solves my problem”.

We thus realize that the User Story is a huge paradigm shift in the way to approach the work to be done. A contract here is not made, rather, you are trying to help your user to solve a problem. If you don’t see your user stories as discussion tools with a real user, then you are actually not using User Stories.

This post can grow bigger and bigger, and seems that when people attempt describe the notions “User Story” and “user requirement”, such descriptions come from their experience, and how they use each of them. Going through the comparisons above may not reveal clearly the differences between both terms. For that, we chose to interview Agile experts about this issue, for which answers will be shown in the next post.

Stay tuned until then, and don’t hesitate to share your views in this topic, and how you approach those two terms.