I received two questions this week about how well does agile allow you to do traceability matrix. Very well is the short answer. Here’s why.
If you commit to implementing features (not chunks of architecture) based on user stories in an iteration, you know what you’re planning before the iteration starts. Because you’re working in a timeboxed iteration, and the testing is incorporated into the iteration, there’s no (ok, very little) time lag between the time you know what a requirement is supposed to be, and the time the requirement is implemented and tested. Now it’s a simple matter of paperwork (ok, maybe not trivial) to match the requirement with the code and the test. If you do test-driven development, and start with user-facing tests, it’s even easier.
The shorter your timebox, the easier traceability is. That’s because you have fewer features and fewer tests to manage.
Some of my clients keep their index cards and organize the traceability that way, with notes about where the tests are. They lock the index cards (post-iteration) in a fireproof safe. Other folks use a spreadsheet for the organizing. They use a source control system to manage the changes to the file.
Remember, the requirement is to trace the requirements through the code and tests and to be able to show you did that. The fewer artifacts, the better.
