Monday, April 12, 2004

End-to-end Traceability

Whilst I was writing the book, and publishing the drafts on the Web for review, I got some feedback from a reader who said, “As an agile guy I’m surprised to hear you advocating end-to-end traceability. That seems the antithesis of light weight to me.”

I realized that end-to-end traceability meant something very different in this reader’s mind than it did to me. In fact, anyone from the defense industry probably thinks of end-to-end and documentation in the same thought. The term “end-to-end” really relates to the audit trail of documentation, who touched it, when it was modified or updated and how one document relates to another.

When I’m talking about end-to-end, I’m talking about being able to track value throughout the process. End-to-end means being able to identify the feature a developer is coding or tester is testing and to unambiguously trace that back to a requirements definition in a Product Requirement Document, a Request for Proposal or some analysis artifact such as a Use Case. The purpose is to communicate the potential value being created in the system of software engineering. Such that the consumer, the customer or the product visionary can know how much of the desired product or service exists at any given point.

I track the flow of value with cumulative flow diagrams (CFDs). It’s important to be able to relate the inventory in the CFD to the other artifacts in the project so that the data can be communicated project wide and not just to the development team. It’s not important for value tracking to have the audit trail of documents but it is important to know the milestone progress of each unit of inventory derived out of the initial requirements.