Scrum and Regulation: Delivering Compliant Products in Agile Teams
The assumption that regulated industries require waterfall development is one of the most persistent and damaging myths in software delivery. It persists because it is partly true: regulated industries do impose requirements that many agile teams have not thought through carefully. But the implication that agile is incompatible with regulation is false, and acting on it is expensive. Organisations that adopt this assumption end up running slow, document-heavy waterfall processes that produce neither the speed of agile nor the genuine compliance assurance of a well-implemented regulated development lifecycle. The starting point for getting this right is understanding what regulators actually require — not what traditional teams assumed they required.
What compliance actually requires
Regulatory frameworks like IEC 62304 for medical device software, 21 CFR Part 11 for electronic records in pharmaceutical development, and the EU Medical Device Regulation do not specify that organisations must use waterfall methods. They specify outcomes: software must be developed with defined processes; requirements must be documented; design outputs must be traceable to design inputs; testing must demonstrate that requirements are met; changes must be controlled and documented. None of those outcomes are waterfall-specific. All of them are achievable within a well-structured Scrum process if the team builds compliance into the sprint rather than treating it as a phase at the end.
How Scrum teams actually comply
Traceability from user story to test evidence. The traceability requirement — that design inputs can be traced to design outputs and test evidence — is achievable in Scrum if it is built into the sprint workflow rather than reconstructed from documentation after the fact. In practice, this means linking user stories to acceptance criteria that are written as verifiable requirements, and linking test results to the story and criteria they validate. Done in the sprint, this produces a living traceability matrix that is current with the code. Done at the end of a release, it produces a document that nobody trusts and that auditors increasingly scrutinise for gaps.
Validated sprint review records. The sprint review is the natural mechanism for demonstrating that a sprint's deliverable meets its requirements. For regulated environments, this means the sprint review must be documented — who attended, what was demonstrated, what was accepted, what was deferred, and the basis on which acceptance decisions were made. This is not onerous: a structured template completed at each sprint review provides the audit evidence that many regulated teams currently produce through elaborate post-hoc documentation exercises.
Risk-based testing intensity. Regulatory frameworks typically require that testing intensity be proportionate to risk. IEC 62304, for example, classifies software by safety class — A (no injury possible), B (non-serious injury possible), C (serious injury possible) — and specifies different rigour requirements for each class. Scrum teams in regulated environments should classify each user story by the safety or compliance risk of the feature it implements, and the Definition of Done for that story should reflect the testing rigour required for its risk class. A feature that affects drug dosage calculation requires different test coverage than one that changes the colour of a dashboard.
Regulatory-aware Definition of Done. The most powerful single change a Scrum team in a regulated environment can make is to build compliance requirements into the Definition of Done. When traceability, risk classification, test evidence, and review documentation are required before a story is accepted as done, compliance becomes an integrated part of delivery rather than a phase at the end. The first few sprints under this definition feel slower. Every sprint thereafter is faster than the equivalent waterfall phase, and the compliance artefacts are produced as a byproduct of delivery rather than as a separate workstream.
What traditional teams got wrong
Traditional regulated development often confused the appearance of compliance with genuine compliance. Producing a thousand-page Software Requirements Specification that nobody reads and that diverges from the implemented software is not compliant — it is a liability. Regulators have become increasingly sophisticated about this distinction. The FDA's own guidance on agile in medical device software development, published in 2019, explicitly acknowledges that agile approaches can satisfy regulatory requirements and in some respects produce better evidence than the document-heavy waterfall practices they are replacing. The question for regulated organisations is not whether agile is allowed — it is whether their agile implementation is producing the evidence regulators actually require.
If your organisation is navigating how to adopt agile without losing compliance assurance, or if you are facing an audit that requires evidence your current process cannot easily produce, XNM's program and project delivery advisory works with regulated organisations to build Scrum implementations that satisfy their regulatory obligations without sacrificing the delivery speed that makes agile worth doing.