Traceability Matrix in an Agile Project
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 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?
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.
Something tools should do, not people.
A good work item/task tracking system that also integrates with your source control will provide 90% of what people want out of what they call traceability for very low effort. Some systems may require a little creativity for this, but it certainly can be acheived with the tools out there without sending someone scurrying around updating some massive spreadsheet noone looks at ever.
Re: Something tools should do, not people.
but it certainly can be acheived with the tools out there without sending someone scurrying around updating some massive spreadsheet noone looks at ever
Very true. I haven't looked at the traceability matrix document to do anything worthwhile in whatever years I have been in the industry so far.
Would you like to share the tools that helped you achieve 90% valuable information with the community?
Brandon Holt, Preston Briggs, Luis Ceze, Mark Oskin May 21, 2015
Kai Kreuzer, Olaf Weinmann May 21, 2015