Three reasons why basic requirement mapping document is a must for successful agile delivery

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.

Suresh Srinivasan

Director - QA, Virtusa. Suresh is an electrical engineer and holds a masters degree in business administration, with 24+ years of experience in software testing and development. He has worked in different industry domains including manufacturing, Telecom, Insurance, Banking and Logistics. Suresh started his career in testing from the industrial automation and industrial robotics programming and also specialized in business system software testing in multiple domains like Banking, Finance, Logistics, Healthcare, Telecom etc. Currently, at Virtusa he is playing the role of QA practice head for the company's various technology centers in India. He is also a hands-on player on specialized testing and heads some of the activities in this area. During his more than two decades career, Suresh has traveled worldwide to implement various testing projects, covering test automation, SOA testing and performance testing, for global enterprises. Suresh has experience in implementing testing methodologies and concepts from ATLM, TPI, TMAP and TMM. He is also working closely with tool vendors like Rational, HP and iTKO. Leveraging his experience, Suresh has also developed process frameworks for executing testing projects end-to-end which reduces the cycle time while improving the test coverage. He has presented papers on testing solutions at various international testing conferences. Apart from working closely with different educational institutions, Suresh conducts seminars related to software testing so as to bring provide and showcase the practical view to students.

More Posts