The GAMP 5 framework/five-phase approach (Refer Fig) provides a structured approach to validation that can be applied to agile development processes. This framework is based on a risk-based approach, identifying potential risks and implementing appropriate controls to mitigate those risks.

Planning: Determine the scope and strategy of the validation effort and develop a validation plan that includes identification of critical processes and requirements.

Specify: The delivered description of system functionality is provided by the list of completed agile artifacts, such as epics and user stories, taken directly from agile software development tools.

Configure and/or Code: In this step, the supplier relies on its expertise to implement the customer’s requirements. All functionalities documented in the previous steps are implemented.

Verify: Verify that the software meets user requirements and design specifications through testing and other validation activities, such as peer reviews and code inspections.
Report: The validation report will summarize the outcome of the validation activities and assess and classify any outstanding items.

These 5 phases are typically conducted in iterative cycles, with each cycle resulting in a working software increment. At the end of each cycle, the software increment is validated to ensure that it meets the user requirements and design specifications.

Validation Strategy

The validation strategy should outline the validation approach, including the scope, objectives, and should provide a roadmap for validation activities, including testing, documentation, and communication. These documents should be updated throughout the development cycle, reflecting changes in the system’s functionality or regulatory requirements.

When performing validations using this Agile strategy, the validation plan must clearly state/include the list of supporting systems used to manage the required validation supporting records/evidences (Agile validation environment/ecosystem).

Critical Elements in Agile Documentation

Documentation should be concise and focused, and includes the following elements:

• User Stories: These are short descriptions of the functionality that the software should provide, written from the perspective of the end user.
• Acceptance Criteria: These are the specific conditions that must be met for a user story to be considered complete.
• Wireframes: These are simple sketches or mockups of the user interface, which show the layout and functionality of the software.
• Technical Design: This is a high-level overview of the technical architecture and components of the software, and how they will fit together.
• Release Notes: These are brief summaries of the new features and improvements that have been added in each release of the software.
• FAQs: These are answers to common questions about the software, such as how to install it or how to use specific features.

By incorporating validation into each sprint or iteration, using automated testing tools, communicating frequently, and documenting thoroughly, developers, testers, and stakeholders can work together to ensure that computerized systems meet regulatory requirements and are fit for their intended use.

Note: One key aspect of agile documentation is that it is created and maintained by the development team, rather than being handed off to a separate documentation team. This helps to ensure that the documentation accurately reflects the current state of the project and can be updated quickly as needed.