User stories are talked about here (The Beauty of a User Story) and are commonly equated to requirements, you know, what we provide in the Business Requirements Document. So is it true, that user stories are the same as business requirements?

If you read the blog, you will hopefully recall that user stories:

... are simple, short descriptions of the desired functionality of a system, without any technical jargon ... a user story is written from the perspective of a specified user (role or class of user).

On the other hand, a requirement defines what a development teams need to build without giving the user’s perspective. The Product Owner or as has been traditionally done, a Business Analyst, may state the requirements, often in conjunction with technical leads.

Think of what are called the non-functional business requirements, and as an example, the security features or infrastructure requirements that the system needs. These will often not be customer facing.

Consider the two examples:

• User story example: As a customer, I want to be able to reset my password so that I can access the system if I forget it.
• Requirement example: The user must be able to reset their password once they requested a new password and have received a password reset email. The email should contain a unique link for resetting the password and that link should expire after 15 minutes. Valid passwords are detailed in the business rules section in the appendix and conform with Group security requirements.

Knowing this may not help you to write better user stories, but it will at least give you a bit of background on what user stories are and how writing these are different to what was documented as a requirement.

INVEST

INVEST is an acronym which encompasses the following ideas, and are necessary to make up a good user story:

• Independent - if you reorder the item in the backlog it should make no difference
• Negotiable - a user story is a discussion
• Valuable - it solves a problem, the '.... so that ... ' part
• Estimable - it needs to have a Return On Investment attributable
• Small - small reduces ambiguity should be doable in one iteration
• Testable - tests or acceptance criteria to prove it is 'Done'

Qualities of a Good Requirement

A good requirement is considered to have the following qualities and has some overlap with a good quality user story. I've put in brackets how it has that quality in common with a user story. 

• Atomic - self-contained and capable of being understood independently of other requirements or designs. (Independent)
• Complete - enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
• Consistent - aligned with the identified needs of the stakeholders and not conflicting with other requirements. (negotiation should highlight consistency)
• Concise - contains no extraneous and unnecessary content. (small)
• Feasible - reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
• Unambiguous - the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need. (small)
• Testable - able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design. (Testable)
• Prioritized - ranked, grouped, or negotiated in terms of importance and value against all other requirements. (Estimable, Valuable)
• Understandable - represented using common terminology of the audience. (valuable)

What stands out is that the user story is not concerned with completeness or feasibility, This will be determined during discussion.