What level of documentation is necessary for the “Agile” delivery model? This remains a persistent question. Agile practices restrict the amount of time spent on preparing reports and documentation manually for all kinds of transactional activities like reviews, test execution reports, audit reports etc., which need to be pulled from the systems and tools as required for the daily scrum calls. The basic requirement mapping document is very much required for the below reasons:
• Requirement grooming: In every agile delivery model, the requirements grow cumulatively over multiple sprints. For both development and maintenance projects an impact analysis based regression testing needs to be done because running the full regression test cases for each sprint is impractical considering the timelines available for the sprint. We may have to deal with 10+ year old legacy systems while implementing a change where regression testing needs to be done in a short span of time. Only selective regression testing is possible using impact analysis based on typical Requirement Traceability Matrix (RTM) and for all the implemented requirements. So RTM is very important both for development and testing processes.
Requirement traceability can be built using a tool so that it makes it available online. At a minimum it has to be maintained in an Excel spreadsheet to understand the impact of any change being implemented. Without RTM, implementing any requirement within sprint timelines with confidence would be a challenge.
• Documentation of user stories: As requirements are finalized during the initial days of a sprint, the documented user stories are necessary with all details requisite for implementation and testing. Without proper documentation of user stories, content implemented would become grey over a period of time and will be detrimental to the change management process. Without such reference, documentation implementation of a change would take more time and will affect sprint timelines. If the documentation of user stories is done progressively over the sprints, it will not be too heavy, as we are dealing with small pieces of work in a sprint. If it is cumulated for a long time without documentation then it may call for an investment to build documentation and yet the quality would become questionable.
• Resourcing: In general with Agile projects, due to the dynamic nature, we may need to bring in different skill sets as and when required for specific development and testing activities. A resource may not be retained for months and years in any Agile project. In this kind of a scenario, knowledge transfer and preparation of the resource to implement a change can be a challenging and important activity. And minimum documentation will not help ramp up any resource though the scope of the sprint can be limited.
If it is a legacy product or project with 10 to 15+ years of existence, it is very important to have the RTM to understand the impact of any change we are going to make in the existing system for the current sprint.
Overall, we require the documented requirements to be stored and maintained in a tool or in any other format along with RTM to assess the impact of any change. Without such analysis, before implementing a change, the quality of the sprint cannot be guaranteed. These documents need to be version controlled and maintained in a tool or as retrievable files.