Traceability Matrix in an Agile Project

Posted by Vikas Hazrati on Jun 06, 2008 02:00 PM

Community

Agile

Topics

Artifacts & Tools

Tags

Complementary Practices ,

Lean

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.

1. Back to top

   Something tools should do, not people.

   Jun 6, 2008 3:48 PM by Jim Leonardo

   I think traceability is one of those things that everyone would want if it is free or low cost [timewise]. Traceability matrices are brute force attempts at providing a solution to the need.
   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.

   Reply

2. Back to top

   Re: Something tools should do, not people.

   Jun 7, 2008 12:27 AM by Vikas Hazrati

   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?

   Reply

3. Back to top

   Misleading title!

   Jun 12, 2008 7:33 AM by Rob Brown

   I clicked the title thinking there would be new insight for me to handle client requirements to manage a traceability on projects in some kind of automated matrix way, and came up with known reasons why it is time and cost expensive AND does not usually provide the value (knowledge retention) sought - things I already knew. As externals there is always an obligation to guard against future unknown destructive efforts AND try to leave the client with a centralised store of hard-won valuable knowledge that the client's people can use. Wikis and Search-based traceability are the simplest and most valuable in my opinion but are not good enough for the corporate people who regularly need to on-demand-justify their positions to people who only see numbers.

   Reply

• Older >