First of all, let me make it clear that I am a software developer and that I am writing this ISO help with my desire to agile-ize my project management and get a buy-in for changing some general
requirements documentation technique that my team follows. Please do not confuse it with seeking people management advice, I am aware that is off topic on this forum.
I will try to make it simple and clear. When I was hired into my contract position a few months ago, I was told the team was following
Agile but not all the way and that they were open to making further advancement towards it. Once started, I realized that the instilled workflow habits and procedures are still very much
waterfall and that very comprehensive requirements documents are written sometimes several months before any development begins. By "comprehensive", I mean that, while a requirement does cover a coherent and interrelated functional unit, it is by no means atomic and that it can be further broken down into a hierarchy of individually atomic albeit interdependent units of work.
My hope was that each atomic, meaning not possible to further slice it into smaller chunks, unit of progress should have its own
sprint/iteration and its own requirements document. From the development perspective, a clear advantage of this is that I don't have to grasp a wider requirements document, which leaves more focus on the direct task at hand, resulting in better quality work. It is like being handed two different tasks for installing a door and painting a room when the two can conveniently be split into two tasks: you first install the door, then you paint the room. In our current setup, it is a single requirements document, which makes it difficult to grasp or even find the specifics of the concrete task at hand in a document that encompasses other tasks as well.
I am asking this question to confirm that my idea does conform to the official Agile doctrine and that I am not misunderstanding. Should Agile requirements always be as minimal as possible or are there benefits to bundling multiple interdependent work tasks together into a comprehensive document? From the perspective of my cognitive styles and preferences, having the project management side of the team
break down the work into individual atomic tasks would enable me to have to do less project management myself and actually focus more attention on coding rather than structuring increments towards the final objective. Another advantage is that it would be much easier to give LOE and completion estimates on a more narrowly scoped task than a whole project.