In traceability matrix the links between requirements and tests can help answer:

  • Which requirements is almost never tested, and which is 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 traditional sense. Well, stories describe requirements but when you complete 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 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...


4 Answers 4


Tracebility matrix is a tool. It doesn't have any inheritent value, but it might be easiest way of mapping certain kind 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.


I have never seen such a matrix and never heard of it before :-(.

Your goal:

Which requirements is almost never tested, and which is tested extremely often?

can be achived by agile/technical means:

  • Using Behavior driven development bdd as automated test for a userstory to verify that it is complete and still working.
  • There are code coverage tools that show which production code is (not) touched by the tests.

However, I don't know how to answer your second question.

Will a change to a particular requirement cause revisions to a huge number of tests in the system?

  • Thanks. How BDD is going to tell me which requirements are never tested?
    – dzieciou
    Commented Nov 2, 2012 at 17:04
  • The codecovarage tells you which code-fragments were not called in the tests. If you identify to which userstory the untested code belongs to you know which userstories are untested.
    – k3b
    Commented Nov 2, 2012 at 17:11
  • Code coverage and story coverage are not the same thing. Linking the code and story might not be so straightforward I would prefer black-box approach :-)
    – dzieciou
    Commented Nov 2, 2012 at 17:16

In an agile environment you can (should) replace these traditional tools by their agile equivalent.

Instead of having a matrix in some documented format (eg.: Excel sheet with the requirement and there place of implementation) you can use your tests.

For each requirements you are going to have some tests implemented (assuming TDD). These tests then can be mapped straight to the code (what code part do they cover?). This then can be used as an agile bidirectional traceability tool.

This could work very well, though I have never seen this thing in practice. It is quite uncommon to have even the traditional matrix.


I kind of disagree with both dzieciou and Attila for two reasons.

  • They mix up a process (TDD/BDD) which may lead to good coverage with a tool that measures coverage.
  • They're too dogmatic in the sense of "in agile, everything is different and better than it ever was". There's no point in saying "BDD is soo good, you don't even have to measure the outcome"

In my eyes, agile means to not be dogmatic about tools or process steps, but to improve things continously. Use tools that are appropriate for your particular project.

A traceability matrix answers questions which are relevant in agile development. If uses wisely, you benefit a lot from traceability mainenance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.