User Story vs Requirement

Question

User Story captures what the user wants to do with the system at a high level. I understand that the user story would further drive a number low level requirements. Is user story same as high level requirement for the system?

Answer 1

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".

It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in well-written functional requirements. It's just as easy to write a bad user story as it is to write a bad requirement ("as [our company name], I want [vague feature] so that I can [do something that's self-evidently part of my job, like 'sell more to customers']").

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.

Of course, for the aforementioned distinction to matter, your customers and/or senior management must embrace it; it does you no good whatsoever if you have 30 user stories all grouped into a "project" that must all be completed at the same time. You might as well call them "requirements" in that case because they are in fact required.

Answer 2

Ron Jeffries wrote a long time ago about the 3Cs of user stories (http://xprogramming.com/articles/expcardconversationconfirmation/) with the emphasis on a card (short description), conversation between the customers and the delivery team once a user story becomes actionable, and the agreed confirmation of a story after that conversation.

essentially, before the conversation, user stories are just planned scope - rough ideas about what we might do. after the conversation, you should have a way to confirm that the story is complete. So depending on the time when you look at the story in this timeline, a story might be just a broad idea about scope, or a detailed requirement.

these days, the meaning of "user story" seems to be narrowed to just the "card" part of Jeffries' 3Cs. in that case, a user story is not a requirement but a promise to hold a conversation about the requriements.

You can find a ton of gold nuggets of wisdom about user stories on the c2 wiki (http://xp.c2.com/UserStory.html)

Answer 3

To me, a critical element of a User Story is that it captures Why and How a user uses the system. It is especially useful because it does not specify much in the way of how the system delivers the required functionality. When UI and Usability testing is needed, the User Story may be the most important document.

Sure, you can have selenium verify that certain nodes are present in the HTML or take screen shots, or verify that certain pixels are where you hope that they are. But if there is misleading text, or it is not apparent how the user should use the system or it is hard for a user to figure out how to achieve their goal, suddenly you don't have a complete system any more. Now training is required in order to use the system. Reviewing the completed system against the user scenarios is a critical component of manual testing.

There is a mind set captured in user stories/scenarios which should influence many detailed design decisions about the implementation. Unless developers talk directly to users or watch them use the system, the user scenario may be the only link to allow them to understand user needs.

Finally, they allow the business people to specify what they need without suggesting how that should be achieved. It is much easier to describe a solution, than a need, and user scenarios provide a framework for describing needs without proposing a specific solution. The most common business requirement I've heard is, "I want it to be just like Excel, but on the web" which has never yet been what they actually needed.

So I would say that a good story should not include any specific details about how the system should be implemented. It should say, "Once a month, system A needs to be updated with any new data from system B. That data may require corrections. The client has a history of inputting invalid data and not realizing the problem for weeks." It should not say, "The system must accept a latin1 CSV file at least once a month and throw a NumberFormatException if column 3 is not a number." Do you see the difference? The scenario describes the need, not any specific solution. Then in testing you circle back to the scenario to make sure that the solution fits the need. Requirements may mix some needs with some solutions, or even focus entirely on solutions.

Answer 4

User stories and requirements are very different beasts.

Requirements

Requirements presuppose that the design of the application is done beforehand, and that development is the implementation of that design. Requirements therefore focus on how to implement a functionality.

Example of requirement:

• Build a user contact form with the following fields: name, surname, email, free text and a submit button. When the submit button is pressed, an email is sent to our support team.

User stories

User stories focus on what to achieve, and insist that the design of the product is done at the last minute and it is a collaboration between a product person and a developer person. The details are decided during implementation based on opportunity.

Example of a story:

• As Jimmy the user I want to contact your support team when I can't use the site properly so they can help me.

What is the difference?

As you can see, there is certainly a difference in the amount of details provided, but there is also a lot of information that is only available in the story, namely the purpose what it is that we are trying to achieve with this feature.

While it may appear that the purpose is relatively unimportant, this is a wrong assumption in agile development. There are typically two cases in which knowing the purpose is very important: reducing the cost of opportunity and enabling agility.

Cost of opportunity

If there are hidden assumptions in the requirement, it could be very hard to achieve. For example: is there a mail server available? If not, the requirement might take a much longer time to be developed. In some other cases a simpler way of achieving the same goal might be missed because of the design.

In contrast, the user story is about a user contacting our support department. If sending a mail is unfeasible or too expensive, we can devise a different solution on the spot: write to a database, for example, or use a form via Google docs, or simply put an email address instead of the form. This can't be easily done with a requirement, but it's easily done with a story and a product person present.

Agility

For this reason, with requirements we generally tend to think of these hidden assumptions beforehand and make sure there are no hitches. So in this case there might be a different requirement, scheduled before hand, which made sure a mail server was present.

This leads us to another huge difference between stories and requirements which is hierarchy. As I've exemplified above, requirements must, by their own nature, be ordered in some natural hierarchy so that dependencies are met. Stories, on the other hand, focus on purpose and have no such constraints.

This is by design, as in agile it is of fundamental importance to add, remove, reschedule and modify stories as needed during the execution of the project. Requirements can generally be added, sometimes modified or removed, but it's generally very painful to move them around because of all the dependencies. It is simply not done very often. If you are working with requirements, your agile implementation will suffer, or will probably not be very agile at all, in the sense of being able to embrace change.

Answer 5

Stumbled upon this during a google search and thought I would throw my opinion in.

There is really no difference between a requirement and a user story. Both are stating the desired outcome or goal from a user perspective.

The only difference is the way this goal or outcome is captured by a business analyst. In this case it is in the wording.

Example:

As a team lead I want to view which of my team are working on mortgage cases so that I can monitor their performance.

The solution shall display team members working on mortgage cases.

Both of the above could be interpreted in the same way but both also have a lot of ambiguity. The main point here is a difference in style. I think the issue we mostly see is how far into defining the solution do we go before we have moved out of the world of requirement and into the world of functional design. Is it down to the business analyst to state "list logged in users by first and second name on the main application menu" or is that too much information? When we are sat talking to our stakeholders and we all know the solution and can interpret what it will look like, even the likely code language it will be built on and the way it will deployed do we really need to play the pureist game of "let's define objectives and not solutions". This is where I feel the confusion really is.

Requirements often make the assumption we know nothing about the solution just desired outcomes. Yes this makes everything solution agnostic but does that really help us in the development cycle? If we can accurately define something early then why not do it?

All in all though I would not worry about user stories and requirements differences. Ultimately you want to define enough information for.someone to develop a solution. A user story that is too high level will simply be knocked back and requested to be broken down into smaller user stories. The same as a " the system shall" style.requirement will probably be knocked back as being too ambiguous if it does not have enough detail.

In the end go with what your developers and stakeholders like to see and work from that.

Answer 6

I think there is a lot of inconsistency on what the word requirements means, even within classic text books. The same inconsistency applies to user stories. Different organizations and textbooks treat these terms differently. For example, How Roger Pressman's classic Software Engineering textbook talks about requirements is quite different than Dean Leffingwell's Agile Software Requirements book. I respect them both and they both can be valid.

Requirements can be things we code to that have extraordinary specificity with little left to the imagination. On the other hand, it can be argued that requirements should specify what is the business problem and not specify the solution. I think that it is more nuanced though and the answer is somewhere on a spectrum that is unique to each company and industry (not all software development occurs in IT).

I was taught that requirements elicitation leads to analysis, that leads to design, that leads to architecture that leads to requirements elaboration or specification, that leads to something that can be coded. I don't believe this goes away with agile. The timing of when these things happens does change and that is the most important difference. In the waterfall model, elicitation and elaboration happens early. In lean and scrum, elicitation and elaboration happens at various stages with more elaboration happening as you get closer to implementation in a sprint. As does emergent design work.

In our organization, we are leaning towards the Leffingwell model of Epics, Features and Stories, not as requirements but as work breakdown and prioritization. Requirements are a different thing. Requirements are managed separately because we are required to do so for regulatory agencies. And yet some teams are certainly developing requirements within user stories during program increment and sprint planning.

Answer 7

Functional requirements are usually a formal specification that allow you to know exactly if your software work or not. User story are usually a much more informal way to describe a need of one your user story. It does not specify a rigid specification to determine if the software is "valid" or "invalid". While you can test some part of it, the real completion of a user story (if you do them right) is when your user say "yep, that solve my problem!". Remember the agile manifesto :

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In his book "User Story Applied", Mike Cohn say specifically that some things don't map to user story and you don't have to use only that.

In my own team, we use the following :

• User story : a business need of some kind of user. Emphasis here is on the need, and why does he need it. As other have said, the important here is not to specify how it's done, and to go deep in the real need of the user (ex : he does not need to view data in a table, he need to see the exact value of the data, and he is familiar with table to do just that).
• Bug : An unexpected behaviour of the software that impair normal usage. Usually come with an "Importance" (independant of the priority of development) that rate how much it affect the user workflow.
• Technical debt. Something that does not prevent usage the usage of the software but will impair us, the developers, in the future. Example : some class is hard to read, the build is slow, some code is not unit tested, the IDE show weird warnings...
• Improvement : a change to the software that does not allow new scenarios, but make for a nicer experience. Example : changing the fonts, redesigning a form to make it clearer, adding sensible default to the application, etc.

Functional requirements would not allow us to realize that a feature we implemented don't solve the need of a user, even though our cucumber test pass and we implemented every written word. A story is a discussion, and it's informal. The point is for the implementation guys to understand what is the problematic. They are not a contract tool. If you do "scrum but..." and your story are simply a funny way to write the requirements of the software, then yes, there is no difference.

The point is not the user story, the point is the huge shift in paradigm in the way you approach the work to be done. You are not doing a contract, you are helping some of your user solving a problem. If you don't see your user stories as discussion tool with a real user, then you are not using user stories, you are using a funky requirements syntax.

The rest here is my opinion : user story can never succeed in a unilateral way. You need your customer to work with it. Water-scrum-fall is doomed to be a weird requirement-but-not-requirements mess. If you have a fixed bid contract with specific requirements, don't use iterations and user story, there is no point. Use the rest of the agile toolkit : Automated unit/functional test, code review, continuous integration, refactoring, etc. Ensure that your software is continuously working and that you can ship it at a moment notice. Make it available in its unfinished form to the customer so he can give as much feedback as possible. If you do that my friend, even if you didn't do "User story" and "Scrum", you would have been more agile than many so called "Agile" shop.

Answer 8

I believe that everyone will implement and label everything differently depending on past experience and whatever language works for that company which gets the job done is not worth arguing over.

However, IMO, A User Story follows the Agile's approach of "a customers in the building or the customer is immediately available" approach, where documentation isn't necessarily needed because the details are in the customers head and readily available so a formal SRS may not be required. Now a "Task" of a "User story" is how a developer is going to build the user stories in digestible.

An example user story might be:

As an admin user I want to view my clients data listed in a grid

and a "task" might be:

1. Create a Grid which lists the data to be displayed

2. Enable Sorting on the grid which will sort the column selected

Now each of the tasks is estimated and completed in its respective sprint.

From a "traditional" perspective, where "the customer is hard to get a hold of, we need to write this down so that they can confirm we've got it right before we start planning / coding" approach, the Software Requirement Specification is going to be the ideas that were in the customers head and elicited and then written down and formalized and then baselined and managed.

In this case, a "functional requirement" is the nitty-gritty detail of that SRS, and a part of the larger Idea. So in my opinion, a user story could be seen as a (portion of the) formal "Requirement", and the task of that user story is a (or one of the many) functional-requirement.

In the example user story, the formal "Requirement" would be a lengthy document with flow charts and generally is going to be documentation-centric, as opposed to the more "Agile" approach which is customer-centric.

The difference being, the formal "Requirement" is going to be along the lines of some 10 page document outlining the administration section of the app which indicates some listings will be needed, some role based security, etc.. and then some of the functional requirements will be "the listing grids shall enable sorting", "the user information shall be listed in a grid", etc..

and i do believe these days the terms are all mixed and mingled.. which doesnt matter at all