What's the agile requirement traceability matrix?
In traceability matrix the links between requirements and tests can help answer:
Which requirements are almost never tested, and which are tested extremely often? Will a change to a particular requirement cause revisions to a huge number of tests in the system? In agile there are no requirements but stories, so traceability matrix does not exist in the traditional sense. Well, stories describe requirements but when you complete a story, you close it and then you close an iteration and forget about that story. It is done, accepted, and closed. So maybe this is a reason, why in software we used for planning and tracking of iteration and tests there is no such matrix.
Or maybe my guess is wrong. I'm curious whether you use a kind of traceability matrix (linking stories/epics with tests)?
One place I would see it useful is when you get additional budget/iteration to verify your epic better and you want to decide which stories require additional testing...
Agile requirement traceability matrix is a tool. It doesn't have any inherent value, but it might be the easiest way of mapping certain kinds of relations between tests and requirements. As with any other tool, if it seems to work well, use it. If something else fits better, use that. If the tool nearly fits your need, modify it to give what information you need.
If testing is done long after implementation, some kind of tracking is probably needed to make sure that everything relevant is covered and things are what they are supposed to be. However, if they are tested when they are implemented, it's much easier to make sure that they match the intended. Automating tests that try to make sure that features work also long after should replace the need for tracking the requirement/test linkage manually as they are tested all the time. And in the best case even a large number of broken tests is fixed quite easily by changing things in one place, if DRY principle (don't repeat yourself) is followed.