contractual or organizational standards that require traceability? Right you are! Even in a low-formality, high-discipline method like XP, traceability for specification conformance is ensured by having a mapping between story-cards and their corresponding customer acceptance tests. In the case of XP, the written customer acceptance test is the formal requirements specification, and is written on the back of the same index card as the user-story (high-level use case description) was. Plus, the story-card eventually indicates the estimate, the release and iteration, and completion date (so it is also used for status accounting).
For other agile-methods besides XP, it is more common to see the use of simple tracking tools. Here, too, it is very easy (and exceedingly common) to capture planning, estimation, and completion status. Plus, change-requests typically have a unique name/identifier associated with them that is easy to reference from a use-case and/or a test case (and vice-versa) as well as with a checkout/checkin in the version control repository.
Those are some basic ways of capturing request-level and task-level traceability that are minimally intrusive/invasive and impose low-friction on the development team. If more formal traceability is mandated by contractual, organizational, or industry-imposed standards, then keep in mind the following tips for making traceability and documentation as lean as possible:
- Encapsulation and modularity: If we do a good job of applying encapsulation and modularity to achieve separation of concerns and minimize dependencies, then it becomes less necessary to trace to fine-grained levels of details because odds are that impacts will be localized at the encapsulation boundary of the use-case, package, or class: anything that impacts one element of a well-encapsulated entity will likely impact many elements internal that entity and little of no elements external to that entity. This means it can be sufficient to trace only to the coarse-grained level of features/use-cases and classes/modules instead of their individual requirements/routines.
- Documentation and locality: The principle of locality of reference documentation states that, "The likelihood of keeping all or part of a software artifact consistent with any corresponding text that describes it is inversely proportional to the square of the cognitive distance between them." In other words, out of sight, out of mind! We can apply this principle to help minimize traceability and eliminate redundancy by using fewer artifacts and decrease the distance between related pieces of information in several commonly practiced ways:
- Documentation in the code (e.g., JavaDoc, Perl5 PODs)
- Documentation in the model (e.g., UML with formal/informal text annotations )
- Documentation in a database with links/metadata (e.g., Telelogic DOORS, IBM/Rational RequisitePro)
- User reference manual as requirements spec
- Acceptance tests as requirements spec
- Interface/implementation co-location
We feel that the traditional and the agile camps need not fear each other. SCM can be relatively easily implemented in agile processes without removing the agility, while still providing that bedrock of security that more traditional methods prefer. This requires adapting of the methods implemented, while remaining true to the basic principles of SCM. We would define Agile SCM as the pragmatic application of sound CM principles and practices in accordance with agile values while using lean thinking to serve the needs of the business!