User Stories Are Not Requirements

The creation of Agile approaches was also a reaction against huge and useless requirements documents, either textual or using modeling techniques like UML. All the values of the past should however not be discarded in the requirements activity. In his book “Agile Software Requirements”, Dean Leffingwell explains how user stories are different from use cases and software specifications.

Although user stories do most of the work previously done by software requirements specifications, use cases, and the like, they are materially different in a number of subtle yet critical ways.

• They are not detailed requirements specifications (something a system shall do) but are rather negotiable expressions of intent (it needs to do something about like this).
• They are short, easy to read, and understandable to developers, stakeholders, and users.
• They represent small increments of valued functionality that can be developed in a period of days to week.
• The are relatively easy to estimate, so effort to implement the functionality can be rapidly determined
• They are not carried in large, unwieldy documents but rather organized in lists that can be more easily arranged and rearranged as new information is discovered.
• They are not detailed at the outset of the project but are rather elaborated on a just-in-time basis, thereby avoiding too-early specificity, delays in development, requirements inventory, and an over-constrained statement of the solution.
• They need little or no maintenance and can be safely discarded after implementation.
• User stories, and the code that is created quickly thereafter, serve as inputs to documentation, which is then developed incrementally as well.

Source: Agile Software Requirements, Dean Leffingwell, Addison-Wesley

At the initial stages of the Agile adoption history, some teams though they could completely abandon past practices like written requirements or system documentation, misreading the “working software over comprehensive documentation” statement of the Agile Manifesto. In their mind, user stories and working software should be the only artifacts produced. This attitude could speed the software development process in the short-term, but has also some disadvantages in the long term.

User stories are not a goal, but a tool that can be used to start having conversations with the product owner and users. The initial simple format of user stories – As a (role) I want (something) so that (benefit) – should be expanded with additional information like test acceptance criteria or non-functional requirements. Well-written working software could be considered as requirements but lacks some critical information for long-term maintenance, for instance the performance expectation. User stories and other format like uses cases or BDD complementary techniques that should be used for the complete expression of the software requirements and specifications.