Summary
Agile validation in GxP pharma embeds validation obligations inside each sprint rather than deferring them to a qualification phase at project end. GAMP 5 Second Edition (2022) formally endorses this approach for the first time, providing a dedicated appendix on agile methods in regulated environments. The key structural requirements are that user stories are formally linked to URS entries before development begins, GxP-critical acceptance criteria are tested with traceable evidence before each sprint closes, and a consolidated requirements baseline is maintained across all sprints. CSA enables agile validation by scaling the documentation and testing depth of each sprint to the GAMP 5 risk level of the functionality being delivered — so lower-risk sprints carry proportionate obligations rather than full IQ/OQ/PQ overhead per increment.
Can agile development be used in GxP pharma validation, and what does GAMP 5 say about it?
Yes — and for the first time, GAMP 5 Second Edition (2022) formally says so with a dedicated appendix on agile methods in GxP environments. The obligation to produce traceable evidence for every GxP-critical function doesn't change. What agile changes is when in the project cycle that evidence is produced — inside each sprint rather than in a qualification phase at the end.
The pharma industry's assumption that agile and validation are incompatible rested on a real problem: the traditional V-model depends on frozen requirements, and agile depends on requirements that evolve as users interact with working software. Those two positions genuinely conflict. What changed is not that the conflict went away — it's that GAMP 5 Second Edition and FDA's CSA framework together provide a structured way to run iterative development that satisfies GxP obligations without forcing a choice between speed and compliance.
What Changes in a GxP Sprint
A standard agile sprint closes when the product owner accepts the story. In a GxP environment that acceptance is necessary but not sufficient. The sprint also cannot close until the validation obligations for that sprint's GxP-relevant functionality are complete — tested, evidenced, and linked. This is not a gate after the sprint. It is part of the sprint itself.
| Sprint Activity | Standard Agile | GxP Addition |
|---|
| Sprint Planning | Stories accepted, backlog refined, sprint goal set | + GxP-relevant stories formally linked to URS entries before development starts. Acceptance criteria pre-specified in testable, traceable terms. |
| Development | Build, unit test, peer review, continuous integration | + Regression tests run against all prior validated increments. Failures raised as formal deviations, not just bugs. |
| Sprint Testing | Functional testing, demo to stakeholders | + GxP acceptance criteria executed with recorded evidence. Test scope and any exclusions documented with rationale. |
| Sprint Close | Product owner accepts story — sprint done | + RTM updated, deviations dispositioned, validation status confirmed. Sprint is not closed until both product owner and QA sign off. |
The single biggest failure mode in GxP agile projects: QA is treated as a separate lane that reviews sprint outputs after the sprint closes rather than a member of the sprint team. By the time QA flags a traceability gap in sprint 6, sprint 7 has already started and sprint 5's findings haven't been resolved. Validation debt accumulates faster than it can be cleared.
How CSA Makes Per-Sprint Validation Feasible
The reason agile validation was impractical under traditional CSV was straightforward: applying full IQ/OQ/PQ protocol formality to every two-week sprint generates documentation volume that overwhelms the team. A project with twelve two-week sprints would require twelve formal qualification cycles — even for changes with negligible GxP risk.
CSA resolves this by making per-sprint validation scope proportionate to what the sprint actually delivers. The GAMP 5 category of the functionality in that sprint determines the documentation and testing depth required for that sprint's closure. Not every sprint needs the same validation overhead.
Lower Risk Sprint
Cat 3 / Non-critical Config
Documented acceptance criteria, tester confirmation, evidence recorded. Unscripted testing with rationale accepted under CSA. No formal protocol required.
Medium Risk Sprint
Cat 4 / Critical Configuration
Scripted test cases for GxP-critical configured functions. Vendor evidence referenced for base platform. Formal deviation process if criteria not met.
Higher Risk Sprint
Cat 5 / Custom / Release Logic
Full scripted testing, requirement-to-evidence traceability, formal OQ-level rigour. Regression suite covers all prior validated functionality.
The Three Things That Break GxP Agile in Practice
1.No consolidated requirements baseline across sprints. Individual sprint stories live in Jira or ADO but are never formally consolidated into a master URS. At release, nobody can construct a single requirements document, and the RTM cannot be built because the requirements baseline doesn't exist as a formal artefact.
2.Applying agile to the validation and production environments, not just development. Agile works in the development layer. Attempting to push validated increments to production after every sprint — with a change control event per sprint — overwhelms change management. The agile boundary should end where the validated production environment begins.
3.Treating regression testing as optional sprint hygiene. Sprint 6 may silently break functionality validated in sprint 2. Without an automated regression suite that runs against all prior validated increments, this surfaces only at release — or at inspection. Regression testing in GxP agile is not optional; it is the mechanism that proves each sprint's changes don't invalidate the work of prior sprints.
Where GoVal Fits
GoVal manages agile validation as a native workflow. User stories created at sprint planning are linked directly to URS entries in the platform — the requirements baseline updates live as each sprint adds to it, maintaining a single master document rather than a pile of sprint artefacts. When a sprint closes, GoVal checks that every GxP-flagged story has linked test evidence, open deviations are resolved, and the RTM reflects the sprint's contribution before the sprint can be marked validated. The regression test suite is tracked against the validated increment history, so a new sprint's impact on prior validated functionality is visible in real time.
Related Topics
Frequently Asked Questions
Is agile methodology allowed in GxP pharma validation? +
Yes. GAMP 5 Second Edition (2022) formally endorses agile and iterative development in GxP environments for the first time, with a dedicated appendix on the approach. The draft EU Annex 11 revision (July 2025) also addresses agile acceptance criteria. Agile is compliant provided user stories are formally linked to requirements, acceptance criteria are tested with traceable evidence before each sprint closes, and a consolidated requirements baseline is maintained across all sprints rather than distributed across individual sprint documentation.
How is a GxP sprint different from a standard agile sprint? +
A standard sprint closes when the product owner accepts the story. A GxP sprint has additional close conditions: the story must be linked to a formal URS entry, GxP-critical acceptance criteria must be executed with traceable evidence, deviations must be raised and dispositioned, and the RTM updated. If any of these are incomplete, the sprint is not done in the compliance sense — even if the product owner has accepted it. These obligations sit inside the sprint, not after it.
Does agile validation reduce documentation requirements in pharma? +
Agile does not reduce documentation requirements — it distributes them across sprints rather than concentrating them at the end of a project. The obligation to produce traceable evidence for every GxP-critical function does not change; only the timing does. CSA separately reduces documentation volume for lower-risk functionality by scaling testing depth to risk tier, but this is a CSA benefit, not an agile one. Confusing the two is one of the most common mistakes teams make when combining agile with GxP.
What is rolling wave validation in pharma? +
Rolling wave validation maintains a single, live requirements baseline and validation plan updated incrementally as each sprint adds functionality. Instead of completing the full URS before development begins, requirements are formally added to the master document at sprint planning before each sprint starts. This keeps the baseline current across the project without waiting until the end to reconcile what was built. It is the mechanism that makes agile requirements management compliant with GxP traceability obligations.
What role does CSA play in enabling agile validation? +
CSA enables agile validation by making per-sprint validation scope proportionate rather than uniform. Under traditional CSV, applying full IQ/OQ/PQ formality to every two-week sprint creates unsustainable overhead. CSA scales the obligation per sprint to the GAMP 5 risk level of the functionality delivered: a sprint delivering a low-risk configuration change carries lighter documentation obligations than one changing a batch release calculation. This makes embedded sprint validation feasible without reducing rigour for high-risk increments.
Run GxP-compliant agile without the documentation pile-up
Live requirements baseline, sprint-level DoD, and RTM that updates as you build — in GoVal.
