Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Traceability Matrix in an Agile Project

Traceability Matrix in an Agile Project

This item in japanese

A formal traceability matrix often evokes strong response from the Agile community. In a raging discussion on the Agile Testing Group, Jorge Argus initiated an interesting thread on the need for a traceability matrix in an Agile project.

According to Brad Appleton, the key is, to understand the difference between "traceability" and "traceability matrix". Traceability, is a desired property of the project where a statement is made about the transparency and visibility of important pieces of information and their interrelationships. Traceability matrix on the other hand is one of the possible implementations of traceability.

On similar lines, Michael Bolton added that before getting into the details of, how to create a traceability matrix, one should question the reason behind it.

Someone wants traceability? Ask what they want it for, how often they'll want it, the form in which they'll want it, the forms in which they might be able to accept it--and then ask if the cost will be matched by value.

According to Michael, traceability matrix would only be required when there is a danger of losing corporate memory that is genuinely valuable. If that is not the case then traceability is available in many forms like conversations, stories, strategic themes, histories, logs, journals, source code, automated tests, design documents, daily scrums, email etc.

Scott Amber, in his article “Agile Requirements Best Practices”, questions the need for a traceability matrix. According to him, the perceived relevance of a traceability matrix is to easily perform an impact analysis to a changed requirement. The matrix would show the aspects of the system affected by the change. However, this could easily be achieved without the matrix since there are so many experienced people on the project who know in detail about all aspects of the project. Scott added,

My experience is that traceability matrices are highly overrated because the total cost of ownership (TCO) to maintain such matrices, even if you have specific tools to do so, far outweigh the benefits. Make your project stakeholders aware of the real costs and benefits and let them decide – after all, a traceability matrix is effectively a document and is therefore a business decision to be made by them.


I'm a firm believer in traceability if you have actual regulatory compliance needs, for example the Food and Drug Administration's CFR 21 Part 11 regulations requires it, then clearly you need to conform to those regulations.  I question traceability which is solely motivated by "it's a really good idea"

On the Scrum Development group, Alistair Cockburn provided more strength to the argument by quoting a study

On one project (corporate IT context), we deliberately studied the cost for both installing a traceability tool, and the human labor involved in keeping the information up to date. The cost was so staggeringly high that the client removed the traceability requirement from the contract.

Further reiterating the point Brad Appleton added, that manually creating, updating and maintaining traceability matrices is the most time consuming way of demonstrating traceability.

So is there a way to ensure that traceability matrix can be taken care of automatically?

Ron Jeffries suggested, the easiest way is to make the change and see what tests failed. That would give the developer an idea about where the impact is. On similar lines Mike Beedle suggested,

Within the agile paradigm traceability from code/design to requirements is done through unit and acceptance tests. The tests relfect the traceability of the requirements because they execute specific code that implements the requirments.

Brad Appleton mentioned a possible solution in his blog, according to him he works in very short cycles using TDD. Typical tasks in his cycles are writing a test, code to pass the test, refactor the code, commit the changes. When he does a commit he associates the name or id of the story with the commit. According to him, by doing these short cycles, traceability comes with the ride automatically.

In an article “Lean Traceability: a smattering of strategies and solutions”, cmcrossroads suggested that if there would be an addendum to the Agile manifesto, it would be

Trustworthy Transparency over Tiresome Traceability

According to the article, the idea of traceability is to achieve transparency and identification. There are viable alternatives to formal traceability matrix to achieve these. The team should try to attain lean traceability in accordance with the Agile principles. Some of the options mentioned in the article are

  • Recognize that Traceability is not Tracing

  • Use Version-Control and Change-Tracking Tools

  • Basic Integration between Version-Control & Change-Tracking

  • Task-Based Development (TBD)

  • Test-Driven Development (TDD)

  • Simple Tools: Wikis, and Wiki-based Specification Frameworks

  • Event-Based Traceability (EBT)

  • Search-based Traceability - Traceability without Tracing

  • Simple Search-based Traceability ("Just Google It!")

Based on his experience Alistair remarked on the mailing list,

I have, in 30 years in the business, in industry, research and a little bit in government, NEVER seen a traceability matrix pay off.

If you have a different experience, please tell us when you used it and it paid back the money spent on creating and maintaining it.

As evident from the most people on the Agile community believe that maintaining a formal traceability matrix would be a overkill. Teams should try to find out the reasons behind having a traceability matrix and adopt a lean approach which would help them achieve traceability.

Rate this Article