The Trouble with Tracing: Traceability Dissected

Traceability! Some crave it. others cringe at the very mention of it. For hardcore configuration managers and requirements and systems engineers, it is a fundamental commandment of “responsible” software development. For many hardcore agilists and other developers, the very word evokes a strong “gag” reflex, along with feelings of pain and frustration. Traceability requires work and discipline! So how does traceability add value to our business and how can we make it easier?

Ten Commandments of Traceability
How did traceability become so revered and hated at the same time? Is it just because it’s hard? Are the people who come up with it hard-nosed? Are the folks who complain about it just hard-headed? Or are the activities performed and constraints imposed in the name of traceability simply stated too “hard and fast” with little room for flexibility.

Like it or not, many interpret traditional traceability and CM as rigidly mandating the following “ten commandments” upon the development process:

    1. Thou shalt create and maintain linkages between every requirement to all other requirements that it impacts or decomposes into
    2. Thou shalt create and maintain linkages between every requirement and every configuration item that participates in realizing the requirement
    3. Thou shalt create and maintain linkages from every requirement to all design elements and interfaces that describe or model its implementation
    4. Thou shalt create and maintain linkages from every design element and interface to every source code line and module that implements all or part of the design element
    5. Thou shalt create and maintain linkages from every requirement and interface and module and subroutine to every test-case and test-module and test-subroutine that verifies the requirement is correctly implemented in the product
    6. Thou shalt track and record every request for change (be it for corrective, perfective, adaptive, or preventive purposes) and not allow any changes to any artifact without first ensuring that the change was approved and developer was authorized to make it
    7. Thou shalt create and maintain linkages from every change-request to every corresponding piece of documentation and code/test that is created or modified, along with who made the change, when, where, and why and with verifiable (via audit) evidence that the proper process and procedures were executed to ensure mandated appropriate levels of control and peer review
    8. Thou shalt create an maintain linkages from each change request to its corresponding tasks and the corresponding changes for each task
    9. Thou shalt create and maintain linkages from each change and change-request into the sets of artifacts, elements, codelines, builds, projects, and variants into which it is incorporated
    10. Thou shalt keep all the above data consistent, correct, and complete at all times, and use it to generate any reports or audits necessary upon demand

Most of these are things that can and should be accomplished if traceability exists. Many of them seem much harder or more effort intensive than they really are (or need to be). In other cases, the relative ease or difficulty may be matter of the level of detail to which something should be traced. If things are done without keeping in mind the intended purpose and business use of traceability, then many complaints and inefficiencies can result.

Nine Gripes against Traceability
So what exactly are the things that so many developers, and more recently, some of the agile and lean camps don’t like about traceability? Common complaints are as follows (decide for yourself whether they are invalid or justified, or if there is a better and easier way: 

    • It causes more artifacts, more overhead and more work to create and maintain traceability matrices that are going to get hopelessly out of date because changes are inevitable
    • It encourages “analysis paralysis” and heavy “up front” planning and design
    • It imposes unnecessary restrictions upon the speed and productivity of development
    • It is a fool’s errand that amounts to smoke and mirrors to provide an illusion about control and certainty regarding mostly redundant pieces of information already in the code and the tests
    • It goes against the values in the “Agile Manifesto” because traceability emphasizes comprehensive documentation over working software and contract negotiation over customer collaboration
    • It makes it harder to make necessary changes and encourages rigidity rather than flexibility
    • It assumes a waterfall-based lifecycle with end-of-phase hand-offs to different functional groups
    • It increases the amount of “software waste” for time spent seeking information and increases the duration and amount of “inventory” (partially completed, “in progress” functionality)
    • It doesn’t readily fit iterative development working in short-cycles with close customer collaboration


About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!