The Best of Both Worlds

Agile methodologies are designed to utilize user stories instead of requirements to define an application’s features. User stories provide a context that regimented requirements don’t, enabling developers and testers to better understand how particular features will be used by the intended application users. 

But application development is still largely driven by requirements, mainly because of existing development practices. Many organizations that contract for custom applications—either with their own IT group or with an external application provider—use requirements to define the relationship with the development team. Some projects are controlled by legal or regulatory statutes, which have a long history with requirements. Most teams and customers also understand how to write, manage, and build software to requirements.

So, many agile teams find they have to work with both user stories and requirements. User stories give teams greater flexibility in designing and implementing features but can be more difficult to objectively assess for quality because they tend to be less precise.

How can these teams combine the flexibility of user stories with the precision of traditional requirements?

For requirements and user stories to coexist successfully, teams need to structure their project to take advantage of the best qualities of both. One way is to use requirements as the agreement between the team and the end users. Requirements, which are structured and objective, are best used to define exactly what will be implemented. This includes non-functional aspects of the application, such as security and performance.

User stories can then be used to build a context around those requirements, helping the team understand how a feature will be used. User stories can give the development team a deeper understanding of the feature and its purpose. These stories can be managed with requirements without a lot of additional overhead, as long as they each use different ways of representing the same features. This could mean that each user story supports multiple requirements, or each requirement uses more than one user story.

Developers will rely on user stories when designing and implementing features, referring to requirements for clarification when necessary. Testers will write and run test cases to support requirements because requirements more formally represent the agreement with the users. A good tester will also refer back to the user stories to better understand how to structure the tests, ensuring important features are accurately tested.

 Requirements and user stories are different paths to the same destination—quality software

User stories and requirements have to be linked together for this approach to work. Team members must be able to determine at a glance which user story supports which requirement and vice versa. 

Linking is important for another reason—traceability. Traceability helps teams determine what else, such as test cases and even source code, must change if a requirement or user story changes. If artifacts are linked to requirements and the requirements to user stories, teams can immediately see what else has to change if either a requirement or a user story changes.

Using both requirements and user stories results in a better understanding of the use of the application and the needs of the users. Project teams can work with them to have a better understanding of the business problem while delivering on the needs of the users.