Epics, Features, User Stories, Square Pegs, and Round Holes.

Scrum is a software methodology that promises to manage the inherit complexity, risk, and unknown factors that accompany building software. While it deserves praise for its stance on being flexible and adaptable for a specific project or team, I find that its failure to prescribe specific standards and approaches for capturing system component requirements have been harmful to Scrum-based software development.
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:

1. Forced binding of a software component, or work on a software to a specific user need or feature.
   
2. 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.
   

Creating a User Story for component requirement capturing is very much like trying to fit a square peg into a round hole. The result is a clumsy sounding work order. Misuse of this technique does end up being costly as component requirements grow in complexity and Product Owners begin to account for effort expended for specific benefits. It becomes very difficult to communicate and discuss about component work if teams are pretending that they are Features. An outsider reading about such ‘User Stories’ in the project management tool will be confused. While many experts prescibe the idea that an end user will want a specific level of performance, or the system to be capable of doing something, and that this User Story can be decomposed into component work, I find it difficult at times to be able such a requirement to a single component, and that ,most of the time, component work must be undertaken to serve all Features of the product, and not just one which would be implied by such a practice.
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.