Missing without a trace…
The T-word is a word that strikes fear into the hearts of many Agile practitioners… but does it need to? Can traceability still be relevant and how can it be made more useful across varying delivery approaches, be it waterfall or agile? IT consultants, Project Managers and practitioners at either end of the ‘traceability spectrum’ will give you valid arguments both for and against the use of traceability in a delivery project. These two extremes in approach can lead to either:
- Onerous manual mapping activities into huge traceability matrices, which takes more time, effort and resourcing than the value in the outcome of the exercise, or;
- Lack of understanding for the business of whether all their requirements have been delivered as expected, and/or potential future difficulties when initiating and implementing change for the addition or modification of requirements.
There is no doubt that in a waterfall project, where there is clear phase containment between requirements creation, design, build, test, and deployment, that there is a useful place for traceability. It provides a strong link between what the business has asked for and what the business gets. However, for projects operating an agile approach where the business user is sitting with the programmer and they are working together to develop their application, this sort of documented traceability seems ‘over-the-top’, cumbersome and time-consuming, with little or no benefit to the end product.
So can you have a compact traceability process?
Yes – traceability does not have to mean “traceability matrix”, nor does it necessarily mean ‘over-documentation’… there are a plenty of simple tools out there, that can easily link business user stories to code commits or test results. Furthermore, the use of Task-Based Development or Task-Driven Development in Agile implementations can ensure that traceability is maintained through simple linking of tasks and tests to original User Story / Requirement IDs.
Ultimately, the importance (and level) of traceability will differ depending on the type of business, size of the project, any regulatory dependencies, and the scope and style of the implementation. We should look to use a compact traceability approach in order to provide delivery trust and future-proofing to the business, while reducing overhead and manual effort for the implementation teams.