Traceability Matrix and Agile

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.

6 Replies to “Traceability Matrix and Agile”

  1. Not to “rain on your parade”, but I have yet to see an organization who is really concerned about traceability (government or regulated industries) ever adopt this lightweight tactic. You have GOT to have a tool, or that is what they claim.

    Given that, what would you say is the “root cause” we could address in these environments that would help us get to something more lightweight?

  2. I am happy to see someone address systems engineering concepts such as traceability in the agile model. Of course you can trace in agile. It is one of those things that you just do. The choice of tool depends on the size and complexity of the project and product.

  3. I would like to mention other possibilities to add tracability to the agile projects:
    1) Acceptance tests (And tools like FIT & Fitnesse). If you specify acceptance test for each stories, then it allows you to organize development around them, and supply requirements with acceptance tests.

    Also, agile development allows for reverse traceability – remove some part of code, and run all the tests.
    The tests that fail are affected by the code, which was removed.

    2) Adding Issue-Tracking IDS to submits – allows you (with some tweaking& scripting of issue-tracking system) to see all submits, related to the issue (story)
    There are some tools and plugins to the issue-tracking systems, which allow you to see all the changes to codebase, related to the particular issue.

  4. Dear Johanna,
    Good to read your view about Traceability Matrix and Agile. But an addition to your points. Traceability is not just at a sprint/iteration level but an application level. consider an example where a team worked on a story in sprint 6 and in sprint a user story is given Product owner which requires an enhancement for that sprint 6 user story. In such scenarios how would you address impact analysis.

Leave a Reply