Requirement or User Story is core to any project, software or otherwise. If at the end of the project, user is not happy with the functionality or features, everything goes in vain.

Requirement is a pillar which holds the value of a project.

user story is a pillar which holds the value of scrum agile project.

Different industries follow addresses requirements in different ways, feature/e is the most common term used for requirement. We all are used to the term “Feature” in the world of smartphones and gadgets.

What is a User Story in Scrum Agile?

Requirements are Features.

They are also referred as “Functionality” or “Functionalities”.

In the world of agile software development, like scrum or Kanban, they are referred as User Story. Technically speaking, in case of software development you will hear the term “Requirement” with waterfall projects and “User Story” with Scrum projects.

 

A lot of experts will tell you that user stories are informal description whereas requirements are formal expression of system requirements but as a matter of fact, it all depends upon the organization. Requirement is formal but it doesn’t mean user story could be anything. User story follow the format of;

As a <user>, I want <feature> because <Reason>.

This is the preferred format with some degree of variation which make it a formal structure itself contrary to popular belief that user story is informal description.

The biggest difference you will notice is that the level of details. In waterfall methodology, level of details captured with requirements are much more than level of details captured with Scrum.

For example;

Typical User Story in Scrum Agile Project:

As a <youtube> user, I want <upload button> because <I want to upload videos>.

 

A Typical Requirement in Waterfall Projects;

YouTube should be updated/modified to add a “upload button”. This button should be placed at the top right side of the screen. It should be rectangular and red colored. Its size should be 3 cm X 9 cm.

(ignore the numbers and specifies, these are for demo purpose only and not related to YouTube in anyway).

As you can see, in case of requirement we have more details like location of the button, color and size.

you can use word or excel to maintain user stories.

Who Handles Requirement or User Story?

“Business Analyst” is responsible for requirement elicitation in waterfall projects.

“Product Owner” is responsible for user stories and product backlog (requirement document) in scrum agile.

Most of the scrum agile project follow above mentioned template for capturing user stories or requirements. Essentially these are system requirements (in case of software development),

If you are in commercial development of any product, your entire world is all about Requirements/features/functionalities. So, whether you are creating furniture’s, plumbing material, hardware of any kind or software, requirement is core to what you do.

Requirements should be handled carefully. For customers, anything and everything they want is a requirement, but if you are in the business of developing them, then it isn’t the case for you.

With all the sophisticated apps, hardware and software in the market, there is lot of hype around what could be done with a software. Customers, end users or stakeholders may ask you to add certain requirements/features which are beyond the scope of what you can do in your project.

Requirement should be differentiated from “Desires”, especially in enterprise software development. These is a cost to develop anything, by wasting efforts, time and money on features or functionality which doesn’t delivery value to the organization, you are not doing justice to the business objectives. therefore you must analyze requirements and reject desires which are not adding values.

Therefore, it is very important to maintain the expectation & you should do it at the very initial stage of requirement elicitation sessions..

Requirement scoping is in the context of project where your requirements are valid but maybe not deliverable with given budget or timelines but sometime there are certain requirements which are just beyond the paradigm of the project.

Characteristics of a valid requirement

 

To set the expectation straight and avoid unnecessary back and forth debate around them, you should ensure that requirements are “SMART”.

S- Specific

As mentioned earlier, anything and everything can’t be a requirement or user story. It should be a specific functionality which is relevant in the context of business and specific in terms of need.

M- Measurable

It shouldn’t be something generic, it should be measurable. Generic statements like “it should be very good” or “increase the size of it” or any other statement related to any functionality or value of its impact should be measurable. Requirement should be measurable, expressed in terms of value, if applicable.

A-Attainable

Functionality should be attainable with available budget, timeline, compliance and other constraints. As mentioned earlier, a lot of users will ask you to add functionality based on their common sense or regular perception but with your product or technology, it may not be attainable. For example, there are lots of old fashioned industries like manufacturing, banks and insurance companies which still uses mainframe based products for their backend operations. for these products, there are lot of changes which are either just not possible or need more resources to attain. So, you need to see if requirement is attainable.

R- Realizable

Requirement should be realizable in terms of achieving business objective and delivering value to the organization. So, if you are making a change, it should help organization in realizing its business goals.

T- Traceable

Traceability is one of the quality practice which you must follow to validate requirement. A requirement should be completely traceable, starting from business requirement to its implementation. So if there is a change, it should be traceable to its source.

All requirements should follow these rules. Whether you are following waterfall or scrum agile, requirement should be SMART, in any form you elicit them.

 

 

Characteristics of  a valid user story or stories

Just as we have rules around requirements for validity, we have certain rules for user stories also. I will say, don’t treat them as separate, treat them in addition to SMART rules. Scrum agile user stories should be;

I- Independent

N- Negotiable

V-Valuable

E- Estimable

S- Small

T-Testable

Requirement should be independent means that requirement should deliver a functionality. It should support independent implementation but sometime in few projects, you may come across user stories which are vital to project but are not independent. In these cases, you create batches of user stories which are dependent on each other and producing some complete functionality.

So, depending upon projects, especially in enterprise software development, you may have to modify your approach to fit the project’s need. For example, sprint 1 or 2 may focus on delivering non-functional requirements or functional requirements which provide support for future implementation.

All others are self-descriptive and leave your comments if you have any question about them. But make sure that your user story is testable. If it can’t be tested, it shouldn’t be developed.

 

Who create requirement or user story?

In a conventional waterfall project, business analyst is responsible for requirement elicitation and maintaining requirement documents like Business Requirement Documents and in case of scrum agile, product owner is responsible for maintaining product backlog.

Requirement or user story can come from any user or stakeholder, but it is responsibility of these roles to ensure requirements are analyzed, tracked and maintained. In a product backlog, all requirements must be estimated, prioritized and ordered.