From V-model to Agile

Introduction

Computer System Validation (CSV) is a daily practice in the pharmaceutical and life sciences industries, ensuring systems are fit for their intended use, perform as expected, and comply with regulatory requirements.

ISPE’s GAMP 5 [1] provides the industry’s dominant guidance on validating computerized systems. While the V-model [3] has traditionally been the lifecycle model used under GAMP 5, GAMP 5 explicitly supports other development methodologies [4]. The CSV practice must adapt to the emergence of new software development technologies [1][2].

Support for agile development methodologies is one of the major differences between the first and second editions of GAMP 5. In fact, the second edition (2022) recommends agile processes.

Since GAMP 5 2nd Edition was first drafted:

• FDA finalized its Computer Software Assurance (CSA) for Production and Quality System Software guidance in 2025, superseding Section 6 of the 2002 General Principles of Software Validation guidance. CSA removes the expectation of exhaustive, document-heavy evidence to prioritize risk-based assurance focused on functions that affect product quality and patient safety.
• ISPE published a standalone GAMP® Guide: Artificial Intelligence (July 2025), extending the AI/ML groundwork laid in GAMP 5 2nd Edition’s Appendix D11.
• The EU is midway through the largest rewrite of Annex 11 since 2011, alongside a brand-new Annex 22 on AI, both still in draft as of this writing.

Scope note: CSA is written by FDA’s device centers (CDRH/CBER) for production and quality system software under the device Quality Management System Regulation (QMSR, the amended 21 CFR Part 820). It does not cover Software in a Medical Device or Software as a Medical Device, and it is not itself a pharmaceutical-GMP guidance.

This paper first explains why the IT world has increasingly embraced agile, then dives into the Scrum framework (the most common Agile framework in use), and finally addresses how to adapt CSV processes accordingly.

2. Evolution of software development models

2.1 Sequential predictive models

Professional development methodologies began with a linear, step-by-step approach, where each step’s inputs are the previous step’s outputs. It clarifies expectations and ensures verification and validation, but going back is difficult, and nothing is prepared upfront.

2.1.1 The waterfall model

In the waterfall model, teams write requirements and specifications before implementation begins, then verify and validate. This model’s path is linear. Nothing runs in parallel, and each task fully depends on the one before it.

Business needs → Software requirements → Analysis → Design → Coding and debugging → Testing → Operations, maintenance

Because this model forces completion of each step before moving forward, requirements can’t adapt, documentation becomes heavy, and once you move to the next step, you can’t retreat without effectively starting a new project. (Two minor patches exist — the modified parallel waterfall, which allows backing up one step at a time, and the Sashimi model, which overlaps phases. Neither is in wide GxP use today.)

2.1.2 The V-model and W-model

The V-model decreases abstraction (business needs → detailed implementation) in its first half and increases it again (implementation → business use) in its second half:

Business needs → Software requirements → Analysis → Design → Coding and debugging → Unit testing → Integration testing → System testing → Acceptance testing → Operations, maintenance

This is the “V-model” in a GxP context, and it carries into the IQ/OQ/PQ qualification structure. GAMP 5 scales the V-model by category — a fully custom application (GAMP category 5) gets the full specification/verification ladder; a standard product (category 3) collapses most of that ladder into “requirements specification ↔ requirements testing” against the standard product.

The V-model’s advantage over waterfall is writing verification/validation tests before the corresponding build artifacts exist, running specification and testing in parallel rather than in strict sequence. This “associate each step with a deliverable” approach is the W-model, familiar from equipment qualification (Factory Acceptance Testing / Site Acceptance Testing).

Despite its advantages, the V-model still forces top-down design. End-user behavior must be defined early. Higher-level requirements cannot benefit from good ideas that appear during lower-level design and coding.

VLMcare in practice: The specification-to-test traceability is where the manual V-model breaks down. Teams maintain the link between a requirement and its test case in a spreadsheet or a cross-reference table that falls out of sync the moment either side changes. VLMcare’s object-based model keeps requirements, risk items, and test cases as independent, connected objects and automatically generates the traceability matrix. The system builds the traceability matrix in real time from the live links between objects, including many-to-many relationships.

2.2 Going to agility

Sequential predictive models struggle with requirements that are poorly defined at the outset. To handle changing minds and initial uncertainty while still assuring quality, the industry moved toward more dynamic, flexible methodologies.

2.2.1 The Agile Manifesto

In 2001, seventeen industry experts, reacting to software development processes seen as inefficient, heavyweight, and overly planned, created a new set of values [18]:

These values are expressed as twelve principles. See Appendix B for the “Agile Manifesto.”

2.2.2 The Scrum framework

Scrum complies with the Agile Manifesto and is the most common agile methodology in software development. It’s frequently confused with agile itself, but that’s technically inaccurate. Agile is a set of principles. Scrum is a framework for implementing them.

Every sprint (one Scrum cycle) is intended to produce deliverable software. Sprints are fixed-length, one month or less.

3. Scrum in depth

Scrum applies almost every agile principle (Appendix B) and disrupts whole-company culture, not just the technical level, through self-managing, autonomous teams.

3.1 Overall approach

1. Considers requirements as soon as the idea exists, even if not mature. Maturity comes when needed.
2. Groups requirements into a cycle. A cycle succeeds if the attached requirements are “done” and accepted, and the software is usable.
3. Runs on dedicated, self-managing teams with roles distinct from the company’s org chart.
4. Supports an iterative and adaptive approach, allowing the product to evolve based on inspection, feedback, and emerging requirements.
5. Encourages best practices borrowed from other methodologies (e.g., pair programming).

3.2 The big picture

The product backlog holds everything that might get built, not yet fully defined. Sprint planning selects and refines items into the sprint backlog. The daily scrum keeps the team moving and impediments visible. Items progress to “done” as testing/acceptance criteria are met. The sprint ends with a review (showing stakeholders what’s done) and a retrospective (capturing lessons for next sprint). The product owner continuously refines the backlog between sprints so items are ready for the next planning session.

3.3 Concepts and vocabulary

Wording like “should” and “ideally” represents best practice, not a mandatory rule.

Cycles

Team, roles, and responsibilities

Meetings

Features/requirements management

VLMcare in practice: Requirements and test cases living as independent objects rather than inside static documents is the same idea Scrum is describing with “backlog items” and “acceptance criteria” — VLMcare’s object model gives every requirement, risk item, and test case a permanent page showing its full history, links, and status, and a reusable requirement/test-case repository so teams aren’t rewriting the same content across every new system.

3.4 Life cycles

Scrum’s added value is starting work on a product whose requirements aren’t finalized. This introduces a product backlog item life cycle (refinement → sprint assignment → development → testing → “done” → review confirmation) in addition to the product’s own life cycle, and a sprint life cycle (planning → daily scrums → review → retrospective → release decision), since not every sprint increment needs to become a released product.

3.5–3.6 Relation to other models, and the limits of flexibility

Scrum’s flexibility follows agile’s first value: “individuals and interactions over processes and tools”. Translation: very few procedural “musts.”

But flexibility doesn’t mean a free-for-all. Behaviors that consistently undermine projects include:

• starting work on unrefined items
• reducing the qualification of “done” for hard cases
• excluding stakeholders from the sprint review
• planning without any work-estimation method
• letting daily scrums turn into technical debugging sessions
• assigning blame in retrospectives instead of learning from them
• isolating testers/documenters from the rest of the team
• replacing Scrum roles with the company org chart
• calling a sprint “successful” even when nothing is releasable
• making sweeping mid-sprint changes or refusing all small clarifications during implementation

3.7 Releasable software?

“Releasable” is a technical standard. It only means the features meet the intended functional use, not that regulatory requirements are met (unless that’s explicitly written into the definition of done, which is difficult to reach within normal sprint dynamics). Sprint review testing may be less exhaustive than full regression testing.

3.8 Maturity, Scrum philosophy, and quality assurance

Scrum optimizes for delivering what the customer wants, letting them progressively refine what they need, without extra paperwork.

Scrum is compatible with the ISO 900x definition of quality [14][15]. Still, it removes most of the formal assurance principles — risk management, change control, CAPA — shifting from a priori prevention to a posteriori reaction.

Scrum’s fundamental bargain is that fixing software fast and cheap outweighs the lost assurance, as long as three conditions hold:

1. Rigorous adherence to Scrum principles
2. Professional maturity of the team
3. Understanding that any issue an end user hits has financial or reputational cost

3.9 Impact of flexibility: refactoring

Improving features progressively means PBIs regularly touch previously implemented code — moving, adapting, or rewriting existing structure. This has costs:

• Team resilience in dropping or rethinking work that took meaningful effort in previous sprints
• Testing not just the refactored part but re-verifying anything indirectly impacted

3.10 Tools instead of documents

Scrum’s pace makes the traditional write-review-approve-QA cycle on Word or paper documents quickly unworkable.

Three layers matter:

1. Product conception of requirements, risk items, and test material increasingly managed via ALM software rather than static files.
2. Surrounding documentation like user manuals and validation files.
3. Grey zone of technical documentation, which should live with the code itself.

VLMcare in practice: VLMcare manages the full validation lifecycle — system creation through impact assessment, planning, testing, defect resolution, summary reporting, and “released for use” status — in one platform. This is far more efficient and traceable than a document-and-spreadsheet stack.

4. CSV in a Scrum world

4.1 Challenges

Adopting agile doesn’t mean compromising GAMP 5 adherence. But it does require aligning Scrum’s pace and V-model-derived testing levels.

Testing: Component/unit testing and component integration testing are perfectly doable in Scrum — easily automated, sometimes de facto delivered with test-driven development or a DoD that mandates unit tests. System testing is harder to automate; supporting refactoring at that level often requires advanced techniques like keyword-driven test design, and manual testing usually remains necessary, even as sprint dynamics squeeze testing timeframes. Non-functional testing (security, performance) usually covers ground that isn’t captured by any PBI at all, making it structurally hard to fit into a sprint. The sprint review is the rough equivalent of acceptance testing, but it’s informal and doesn’t cover regression. System integration testing (treating other software/devices as “users”) is complex and, again, usually not represented by any PBI.

Other gaps: Scrum is not naturally good at producing CSV documentation around project quality assurance (validation plan, validation report, requirements specifications), overall product documentation, or feature-specific documentation unless it’s explicitly written into the definition of done.

VLMcare in practice: FMEA-driven risk scoring is designed to close the testing-coverage gap. VLMcare calculates testing rigor automatically from probability, severity, and detectability inputs (none / unscripted / scripted-limited / robust), so the assigned depth of testing for a PBI is bound to its risk score, not how much sprint time remains.

4.2 Mitigation

4.2.1 The “Vrum” approach

Software can be built with Scrum but surrounded by a V-model wrapper for validation purposes: start with light user/system requirements grouped into a backlog; run normal sprints; once the relevant PBIs are done, freeze a code branch for that scope; run CSV activities (and bug fixes, and anything else that doesn’t fit Scrum’s cadence, like extensive manual regression testing) against that frozen branch — potentially with a separate team, so the main Scrum team keeps working on other branches uninterrupted.

Teams that can complete this in one sprint sometimes call it a “wrapper sprint”. The shorthand for this hybrid is “Vrum” — V-model + scrum.

VLMcare in practice: The overhead of freezing a branch and coordinating a separate CSV pass is largely a document management problem. VLMcare’s multi-release management supports multiple parallel releases with a clear “active” designation, and continuous status tracking per item means CSV work on one scope doesn’t have to wait for, or block, ongoing sprint work elsewhere.

4.2.2 Current guidance

• FDA’s CSA guidance is final.
• ISPE’s GAMP 5 2nd Edition (2022) already covers agile directly and explicitly avoids modifying agile to fit GxP or superimposing the V-model onto it. When applied with rigor, the agile model delivers the same QA outcome as the V-model. Its Appendix D11 (extended by the standalone July 2025 GAMP AI Guide) extends the same risk-based logic to AI/ML-enabled systems. This is crucial for validated systems using an AI/ML component or LLM-assisted workflows.

4.3 The GAMP 5 conception phases in V-model vs. Scrum

GAMP 5 frames the system lifecycle as Concept → Project → Operation → Retirement. As a development methodology, Scrum sits within the Concept/Project phases. Comparing V-model to Scrum phase by phase:

Plan. V-model issues the validation project plan, system description, URS, and risk analysis up front as project drivers. Scrum also requires a validation project plan upfront to set the overall validation approach, but it builds the other documents incrementally during refinement and development. The validation plan itself must specify the definition of ready and definition of done.

VLMcare in practice: VLMcare’s System Impact Assessment (SIA) automates the early GxP-impact call with a configurable questionnaire, an automatic conclusion (no subjective judgment call needed), and the ability to scale the same logic across dozens or hundreds of systems without a manual assessment per system.

Specify. The V-model translates user requirements into functional specifications, with a traceability matrix linking requirements to test specifications and referencing procedures like SOPs and change controls, prioritized by criticality. Scrum defines ready/done criteria and builds the product backlog — conceptually similar, except specifications attach to PBIs rather than to discrete lifecycle steps.

Configure and/or code. V-model: the supplier implements documented functionality against its own expertise. Scrum: the team builds a working, potentially shippable increment every sprint, with each PBI owned by a developer and supported by the scrum master/product owner.

Verify. V-model separates verification (unit/integration/functional testing) from validation (user acceptance testing). Scrum tests against DoR/DoD each sprint, with daily stand-ups surfacing obstacles. The definition of done can integrate testing and validation deliverables.

Report. V-model produces a validation report documenting scope changes, vendor reviews, deviations, CAPAs, and fit-for-intended-use conclusions.

VLMcare in practice: Reconstructing a validation report from sprint artifacts is one of the more tedious parts of this transition. VLMcare auto-generates the Validation Summary Report by pulling together requirements, risk, testing, defects, and actions into one report with zero manual compilation, and generates final requirements, test plans, test cases, and RTMs as PDFs pushed straight into the document repository.

4.4 Special considerations when using the agile model

Successful Scrum adoption for validated systems needs validation, documentation, and communication built in as first-class activities, not afterthoughts.

• Validation as an integral part of development: Validation activities happen in each sprint. Automated testing tools that validate functionality after every code change are the practical mechanism.
• Documentation: Incorporated into the development cycle and updated every sprint. Where documents function as electronic records subject to 21 CFR Part 11 (or equivalent EU requirements), the authoring and approval workflow needs traceable, authenticated sign-off.
• Communication: Frequent feedback loops between developers, testers, and stakeholders reduce the risk of unexpected issues.
• Validation strategy: Established before development starts, outlining scope, objectives, and acceptance criteria, with the validation plan providing a living roadmap that gets updated as the system’s functionality or the regulatory landscape shifts.

VLMcare in practice: “Traceable, authenticated sign-off” is a workflow feature. VLMcare routes items for review and/or approval through configurable reviewer/approver lists, captures a Part 11-compliant e-signature record of who reviewed and who approved, and supports continuous per-item status tracking so review doesn’t have to wait for an entire batch to finish before it starts.

4.6 Additional tips

• Automation: test automation and continuous integration (automated nightly builds, unit test/coverage runs, static analysis) are foundational, not optional, for keeping pace with Scrum.
• Design for testing: when a PBI can’t be directly system-tested because connecting components aren’t ready yet, build in stubs and drivers deliberately as a design decision.
• Smoke tests: a fast, low-expertise test suite that answers one question — is this even testable? — letting developers self-assess before formal testing starts.
• One-hour regression testing: the counterpart to smoke tests for existing features — executable in under an hour, ruling out catastrophic regression after refactoring.
• Unit testing coverage: statement coverage and decision/branch coverage, pushed as metrics with negative CI reporting when thresholds aren’t met.
• Risk analysis: critical given how fast and informal changes are in Scrum, often outside any formal change-control process. Most team members can give a “good enough” assessment to guide day-to-day testing; more complex or higher-criticality changes warrant a more formal risk analysis (ICH Q9 [17]).

VLMcare in practice: VLMcare’s built-in FMEA risk analysis (probability × severity × detectability) auto-calculates risk priority and, from it, the required testing depth, with color-coded indicators so the right rigor is visible at a glance rather than re-litigated every sprint. When a test fails, it automatically generates a defect record, classified as blocking or non-blocking, and ties the retest back to the original failure so the loop closes traceably.

5. Conclusion

Scrum offers new value for the life sciences industry. Current guidance aligns with agile methodologies, provided people applying them are trained and aware.

Scrum offers tremendous flexibility. However, the framework demands disciplined adherence within that freedom. Quality requires many conditions to be met, not assumed.

This isn’t an incremental change to how validation gets done — revolution, not evolution.

Appendix A — Abbreviations & acronyms

Appendix B — The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while the items on the right have value, we value the items on the left more.

Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change to give the customer a competitive advantage.
3. Deliver working software frequently, every couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Businesspeople and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective way to convey information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Appendix C — The refactoring pitfall through an example

Consider validating a QMS software product built in Scrum. Release notes for two sprints read:

The validation team validates exactly this: documentation management in sprint N, and CAPA (with a risk analysis confirming no documentation impact) in sprint N+1.

What the release notes didn’t cite: sprint N+1 also included two “enhancements” the product owner graded as uninteresting to end users and therefore didn’t expose:

1. A refactor of the documents database to expose a REST API for a future KPI module
2. A change to compress documents when they’re stored and decompress them when requested

These were real changes to the documentation management system validated in sprint N. Neither appeared in the release notes. The result: a major documentation-management failure in production, traced back to an undocumented refactor.

The lesson: refactoring must be considered for CSV. Since refactoring is normalized in Scrum, it’s essential to ensure every change is documented by a product backlog item and evaluate all PBIs during impact analysis — not just the ones that plainly affect the user interface.

VLMcare in practice: This exact failure mode — a change that’s real but doesn’t surface because it wasn’t “interesting enough” to mention — is what object-level history is built to prevent. Because every requirement, risk item, and test case in VLMcare has a permanent page with its full history, links, and status visible in one view, a refactor that touches an already-validated object shows up as a change to that object, not as a line item someone chose (or forgot) to write into a release note.

Bibliography

1. ISPE, GAMP 5, 2nd ed., 2022.
2. ISPE, GAMP® Guide: Artificial Intelligence, July 2025.
3. Y. Soufyani, “Blog post: What is the GAMP 5 V-model in Computerized System Validation?”, QbD Group, 28 February 2023.
4. J. Boel, “Blog post: What is the agile model in Computerized System Validation?”, QbD Group, 28 March 2023.
5. J. Boel, “White paper: A complete guide to Computer System Validation”, QbD Group, 2023.
6. ISPE, “GAMP Good Practice Guide: Enabling Innovation”, September 2021.
7. A. V. Grados, “White paper: GAMP categories for computerized systems”, QbD Group, 2023.
8. Wikipedia, “Agile software development”, accessed 2023.
9. H. Patrick and v. B. Chris, Advanced test management according to the ISTQB syllabus, Leuven: PSTestWare, 2010.
10. A. Cockburn, “Using Both Incremental and Iterative Development”, Humans and Technology.
11. B. W. Boehm, “A spiral model of software development and enhancement”, ACM SIGSOFT Software Engineering Notes, vol. 11, no. 4, pp. 14–24, 1986.
12. The Scrum Guides, “What is scrum?”
13. Wikipedia, “Jeff Sutherland.”
14. International Organization for Standardization, “ISO 9000 Quality management systems — Fundamentals and vocabulary”, 2015.
15. International Organization for Standardization, “ISO 9001 Quality management systems — Requirements”, 2015.
16. European Commission, “EudraLex — Volume 4 — Good Manufacturing Practice (GMP) guidelines: Annex 11 — Computerized Systems”, 2011.
17. EMA, “ICH guideline Q9(R1) on quality risk management.”
18. K. Beck, M. Beedle, et al., “Manifesto for Agile Software Development”, 2001.