As prescribed, Scrum excels at capturing requirements from the end user, customer, or stakeholders. This is excellent, as this is one of the most difficult tasks of software development, and it is also one of the most important tasks to get done correctly, as it ties in with the work contract itself and the bottom line. Epics, Features, and User Stories are great in that the software team can capture every different kind of want and need of the customer and record it while being able to postpone having to break it down until necessary.
The problem I find throughout the industry, ironically enough, has nothing to do with capturing customer requirements. What Scrum is missing is a way to address the needs of the system itself, and a way to address the needs of the software team and process. When building systems and software, one must acknowledge that the end result is a collection of software components: controllers, clients, databases, loggers, libraries, servers, which should be thought of as vertical blocks system behaviors, in contrast, are features desired by the customer. They are why the software exist, as its through a correctly behaving system that users are able to solve problems, but system behaviors are only possible through correctly orchestrated software components
When starting up a new project, or migrating or extending an existing project, there are steps that must be taken and accounted to provide software components. The fact is that the implementation of a software component often does not map cleanly to a specific user requirement. Typically these map to no requirements, or to all the requirements. Yet the industry standard is to write up such tasks of work as User Stories. I find several problems with this approach:
Forced binding of a software component, or work on a software to a specific user need or feature.
Encouraging teammates to refer to living actors instead of end users when trying to capture the requirement using the ‘User Story template,’ thus creating an invitation for further misuse.
What I would recommend to all Scrum teams are the following ideas: acknowledge the difference between behaviors and components. Reserve the concepts of User Stories, Features, and Epics for the sole purpose of capturing user and customer requirements. Create new terms or conventions for component work, or SDLC work, like Component Work.