If an organization is regulated, it has pass the audit and show that it has implemented a "requirements traceability". Which means it has documented the path from specific requirement to a code change to a working product in production. At least that is how I understand it.
How does this work in Agile/Scrum? Currently, only way I saw this is implemented is as follows:
- Any change, no matter how big or small, needs to have a ticket in an tracker, like Jira.
- This ticket needs to have all the necessities of a specification, before it gets implemented.
- This means things like detailed acceptance criteria and time estimates.
- When implemented, changes to the code must include the tracker ID of the requirement. Either in commit itself or in reviewed pull request.
- The ticket in tracker must follow a pre-defined process of steps from Grooming, In Dev, In QA and finally into Done.
As an XP person myself, I find this extremely stifling. If I were to find a place to make an improvement, I would need to go through that whole process to get it implemented. This process can easily take days or even weeks(I mean in real time, not effort time, lots of time waiting between grooming, planning and implementation). Even when the change itself might take 30 minutes. I understand the need for this kind of documentation, but I'm not versed enough in this specific law to be able to figure out if this is acceptable or not.
Is my understanding of this problem correct? Are there any other ways to implement requirements traceability for regulated organization that doesn't have such big overhead? Or is this something I should learn to live with?