User Stories Handle Everything...
There is an assumption in Agile that by focusing on user stories you are keep the customer's concerns and user's concerns in mind.
This is a bit of a straw man. We want to be mindful of customer and client concerns. User stories do appear to be front facing. But are they really? User stories tell the story of the problem space, not the solution space. What we want from our systems is the ability to tell the user story using the system in a way that is acceptable. This does not tell us how to architect or construct the system.
As an <actor>, I can/want-to <do-some-action> so that <some-business-goal>.
This is all about the problem, not the solution. The gap between the problem space and the solution space is design. So right away we have a mapping problem (a design problem) between the problem and our proposed solution.
The user stories play out on the landscape of the system's services. In this respect, a user story is a description of the problem and a use case or scenario is a strategy for solving a problem. There are usually many such strategies. By only looking at the user stories you are unlikely have clarity around the solution space.
Business can be volatile and chaotic. The need to respond to a changing landscape of opportunities is constant. The software team should provide the ability to carry out the use cases, but protect against volatility. If a system solves only one specific variation of the problem then any change breaks the system. We've all seen this over the years. The smallest of changes to the requirements forces system changes.
Use stories (use cases) play out over our system services. We need this system to be able to tolerate some variation in the business process. If we achieve this, we will have a certain degree of business agility built in to our system. This is not gold plating or extra features. This is robustness. This is a system that is anti-fragile.
Focusing project design on the user stories leads to brittle systems. Thought must be given to the system services as systems in their own right. The user stories inform the system services, but the system services should be architect-ed to stand alone. The collection of services offer the user stories a landscape on which to play out.
This landscape is designed and constructed using sound architectural practices. The plan for construction is created using project design
In Scrum the items in the backlog are "backlog items." Within the Agile community people have started to think of the backlog as only a list of user stories. You hear people refer to the user story backlog. This is not only incorrect, it is dangerous and wasteful.
The backlog of items includes components and services of the architecture. It should also contain the non-software activities. This is especially important when a software component dependends upon a non-software activity.
Treating the backlog as a list of user stories creates an environment of "thin slices." Few things are as wasteful as an unnecessary thin slice.
Plan your architecture to support your user stories. Your user stories do not support your architecture. They are played out on it.
