Agile development is fully compatible with EN 62304:2006+A1:2015 and MDR Annex I Section 17. The standard is process-neutral. It prescribes activities, inputs, outputs, and evidence, not a lifecycle model. Sprints, continuous integration, backlogs, and incremental delivery can all satisfy the standard if the required activities (planning, requirements, architecture, design, verification, configuration management, risk management, problem resolution) happen with documented evidence and closed traceability. The reconciliation move is to map agile artefacts onto EN 62304:2006+A1:2015 activities, define a release boundary that separates internal sprint increments from external medical device releases, and run design controls under EN ISO 13485:2016+A11:2021 clause 7.3 at the release boundary rather than at every sprint.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 does not prescribe a lifecycle model. Agile, waterfall, and hybrid approaches all satisfy the standard if the required activities and evidence exist.
  • The reconciliation is mechanical: map sprints to iterative cycles of the clause 5 development activities, and use clause 8 configuration management plus clause 9 problem resolution as the backbone that connects increments.
  • The release boundary is where the compatibility question is actually decided. Internal sprint increments are not medical device releases. External releases run through clause 5.8 and carry the full design-control evidence.
  • Design controls under EN ISO 13485:2016+A11:2021 clause 7.3 (design and development) apply at the release boundary, not at every sprint. The outputs of many sprints roll up into one clause 7.3 design review and release decision.
  • MDR Annex I Section 17 obliges the manufacturer to develop software under a documented lifecycle reflecting the state of the art. The agile lifecycle is documented in the software development plan, which names the cadence, the artefacts, and the mapping to EN 62304:2006+A1:2015 activities.
  • Agile breaks compliance when documentation is treated as the enemy of shipping, when requirements live only in ticket titles, when traceability is never closed, or when internal increments are deployed to real users without running clause 5.8.
  • The fix is documentation discipline, not slower velocity. Teams that build the evidence capture into the CI and the ticket system ship faster than teams that run a parallel "regulatory documentation" track.

The supposed conflict between agile and EN 62304:2006+A1:2015

Every engineering team we meet that is running scrum, kanban, or a continuous-delivery flow hits the same moment when they start reading EN 62304:2006+A1:2015 for the first time. The standard talks about plans, requirements documents, architecture specifications, verification reports, and release records in a way that sounds like it was written for a waterfall project. The team reads clause 5.1 and thinks they need a big plan up front. They read clause 5.2 and think they need a frozen requirements specification before any coding can start. They read clause 5.3 and think the architecture has to be designed in full before implementation. The conclusion they reach. Almost always wrong. Is that agile is incompatible with the standard and that they will have to abandon the way they work to become compliant.

None of that is in the standard. The standard is process-neutral, and the introduction to EN 62304:2006+A1:2015 says so explicitly. What the standard requires is that the activities happen, that the activities produce documented outputs, that the outputs are verified, and that the traceability from requirements down to verification can be closed. It does not say when the activities happen, in what order, at what granularity, or using what tooling. A team that runs two-week sprints can satisfy every clause of the standard. A team that runs continuous delivery with multiple deployments per day can satisfy every clause of the standard. The compatibility question is not whether agile fits. It does. But whether the specific agile implementation produces the evidence the standard requires.

The first move is to drop the waterfall translation in the reader's head. The standard's clause numbering is not a Gantt chart. It is a list of activities that must exist across the life of the software. When those activities happen, and how often they repeat, is a choice the manufacturer documents in the software development plan.

What agile values translate to in compliance terms

Agile has a set of values. Working software over documentation, responding to change over following a plan, individual interactions over processes. That sound hostile to regulatory work when read at face value. They are not. Read in the context of a competent engineering team, each agile value has a direct compliance translation that actually helps.

"Working software" translates to continuous, automated verification. A team that ships working software every sprint is, by definition, running integration and system tests continuously. That is exactly what EN 62304:2006+A1:2015 clause 5.6 and clause 5.7 require, and the agile team has the evidence baked into the CI pipeline.

"Responding to change" translates to clause 6 software maintenance and clause 9 problem resolution running as first-class processes. Agile teams are already good at this; the compliance move is to document the feedback channels and the decision points, not to build a new process.

"Individual interactions" translates to cross-functional teams where risk, quality, and engineering talk to each other every day. That is stronger compliance ground than a waterfall project where a risk analyst and a developer never meet.

The value that actually needs translating is "working software over comprehensive documentation." The agile reading. "documentation is waste". Is wrong for medical device software. The compliant reading is "documentation that is not used is waste, and documentation that is used must earn its place." The standard does not require comprehensive documentation. It requires specific, traceable outputs. An agile team that captures those outputs as structured artefacts in the repository. Not as Word documents on a shared drive. Is running the right version of the value.

Sprint cycles versus design control records

The practical question every team asks is: do I need to run the full EN 62304:2006+A1:2015 activity stack every sprint? The answer is no. The activities happen continuously across sprints; the design control records close at the release boundary.

Inside a sprint, the team refines requirements from the backlog into specifications for the stories they are picking up. The specifications are traceable artefacts. Issue tracker tickets linked to a requirements document in the repo, or structured markdown files in the repo itself. The team updates the architecture and design documentation for the items being touched. The team implements, runs unit and integration tests, and updates the risk items implicated by the change. The team closes the sprint with an increment that passes the automated verification suite.

None of that is a medical device release. It is internal development activity. The evidence is captured as it happens. Ticket history, CI logs, git history, updated markdown in the repo. But the increment is not released for clinical use. The clause 5.8 release activity has not run.

The design control records in the sense of EN ISO 13485:2016+A11:2021 clause 7.3 close at the release boundary. Multiple sprints of internal activity roll up into one design review, one design verification summary, one design validation summary, and one release decision. The design history file contains the evidence produced across the sprints, organised for the reviewer rather than for the sprint team. The traceability closes at this point: requirements to design to code to tests to validation to release. The team does not run a parallel clause 7.3 review every two weeks; it runs one at the boundary.

This is the distinction that makes agile work under the standard. Internal iteration at sprint cadence, external release at clause 5.8 cadence, design controls at the release boundary. The two cadences are deliberately different.

The release boundary. Where compliance is decided

The release boundary is the single most load-bearing concept in agile under EN 62304:2006+A1:2015. Define it clearly and the rest of the reconciliation falls out naturally. Define it poorly. Or not at all. And the team eventually deploys a sprint increment to real users, and at that moment the internal iteration becomes an unreleased medical device in clinical use.

A release in the sense of EN 62304:2006+A1:2015 clause 5.8 is a controlled activity with documented criteria. All planned activities are complete for the scope of the release. Known anomalies have been evaluated against the risk file. The configuration is identified and reproducible. The release is authorised by the named role. The release record links to the verification evidence, the risk file state, the design review output, and the version identifier.

Internal sprint increments do not meet any of these criteria, and they are not supposed to. They are not releases. They are checkpoints inside the development process. The team can, and should, deploy them to internal test environments, to staging, to developer workstations, to automated test harnesses. They cannot be deployed to production used by real patients or users in any clinical capacity.

The practical move is an environment separation written into the software development plan. Development branches and feature branches feed CI and internal test environments. A release branch feeds a validated staging environment where the clause 5.8 release activity runs. Only verified, authorised, released versions deploy to production. Continuous delivery at the internal cadence is compatible with quarterly or monthly external releases at the clause 5.8 cadence. Continuous delivery directly to patient-facing production without clause 5.8 running between each deployment is not.

For the full release process and its interaction with clause 5.8, see post 387. For the software maintenance process that governs changes after the first release, see post 388.

Where agile breaks compliance. The failure modes

The compatibility is real, but it is not automatic. Agile implementations fail EN 62304:2006+A1:2015 audits in predictable ways, and every failure we have seen maps to one of a short list of patterns.

Requirements living only in ticket titles. A story titled "fix date parsing" is not a software requirement. It is a reference to a discussion. The requirement. What the software shall do, under what conditions, to what performance. Has to exist as a structured artefact that the ticket points to. Teams that skip this step end up with a requirements specification that is the concatenation of every ticket title since project start, which is not traceable and not verifiable.

Traceability that is never closed. Agile teams often intend to close the traceability at the end and never do. By release time the tests have drifted from the requirements, the design has drifted from both, and the team is reconstructing the matrix from memory. The fix is to close traceability every sprint on the items touched that sprint, not to defer it.

Configuration management through branches alone. Git branches are configuration management infrastructure, not configuration management. Clause 8 requires identification of configuration items, version control, change control, and the ability to reproduce a build from the record. A team that treats "the commit hash" as the configuration management record has the infrastructure but not the process. The process is the documented approach that names the items, the identifiers, the change authorisation, and the retention.

Risk management as an end-of-sprint ritual. Risk under EN ISO 14971:2019+A11:2021 is continuous, not a quarterly workshop. Every change that touches a software item contributing to a hazardous situation is a risk-management event. Agile teams that run risk as a once-per-quarter exercise produce a risk file that is always stale relative to the code.

Internal increments deployed to production. The single failure mode that makes compliance impossible. An unreleased increment in clinical use is an unreleased medical device in clinical use, and no amount of subsequent documentation fixes that.

The documentation discipline that makes agile work

The move that separates agile teams who pass audits from agile teams who do not is documentation discipline, applied continuously, built into the tooling, and scoped to the standard's requirements. It is not heavier documentation. It is documentation that lives in the right place and is produced as a by-product of the engineering work.

The software development plan names the agile cadence and the mapping. It says: we run two-week sprints. Clause 5.1 planning is refreshed at each sprint planning and captured in the sprint plan. Clause 5.2 requirements are captured in the requirements document in the repo, updated per story. Clause 5.3 architecture and clause 5.4 detailed design live in the architecture document in the repo, updated per change. Clause 5.5 implementation and clause 5.6 integration are captured in git plus CI. Clause 5.7 system testing runs automatically in CI with logs retained as evidence. Clause 5.8 release runs at the release boundary with a signed release record. Clause 6 maintenance, clause 7 risk, clause 8 configuration management, and clause 9 problem resolution run continuously under named procedures. The plan is ten to fifteen pages and the team reads it.

Artefacts live in the repository. Requirements, architecture, design, risk items, test plans, and release records are markdown or structured text in the same repo as the code, versioned with the code, reviewed with the code. This removes the drift problem almost entirely.

Traceability closes per story. Each story picked into a sprint has a link to the requirement it implements, the design it updates, the tests that verify it, and the risk items it affects. The link is created when the story is picked, not when the audit is scheduled.

Verification evidence is automated. Unit tests, integration tests, system tests, static analysis, and build reproducibility all run in CI. The CI logs are retained as the verification evidence. The team does not write test reports by hand for activities the machine already ran.

For the full development planning activity under EN 62304:2006+A1:2015, see post 379. For the requirements activity, see post 380. For the architecture and detailed design activities, see post 381.

Common mistakes teams make reconciling agile and EN 62304:2006+A1:2015

  • Running a parallel "regulatory documentation" track alongside the engineering work. The two tracks drift. The regulatory track becomes stale and the engineering track becomes unaudited. One track, with artefacts in the repo, works.
  • Assuming every sprint is a release. Sprints are internal checkpoints; releases are clause 5.8 activities with documented criteria. Conflating the two creates either impossible release cadence or unreleased production deployments.
  • Treating the software development plan as a one-time document. The plan is the lifecycle model. When the cadence changes, the tooling changes, or the team changes, the plan updates.
  • Using story points as a proxy for verification. Story points measure team velocity. They do not measure whether the software meets its requirements. Verification is a separate activity with its own evidence.
  • Running risk management as a retrospective activity. Risk is an input to story refinement, not a post-hoc review of what was shipped.
  • Letting the ticket system become the requirements source of truth without a structured requirements artefact behind it. Tickets are references; the requirements artefact is the record.
  • Confusing continuous integration with clause 5.8 release. CI is internal verification. Release is the authorised activity that makes a version available for clinical use.

The Subtract to Ship angle

The reconciliation of agile and EN 62304:2006+A1:2015 is a pure Subtract to Ship exercise. The default reaction is to add a parallel track of regulatory activity that sits alongside the engineering work, duplicates the decision-making, and generates Word documents to match. That track is almost entirely waste. What the standard requires is that the activities happen with documented evidence and closed traceability. Not that a separate team produce a separate set of documents describing what the engineers did.

The subtraction moves that work in this category are these. Collapse the two tracks into one. Engineering work produces regulatory evidence as a by-product, not a second deliverable. Keep artefacts in the repository, not on a shared drive. Close traceability per story, not at release time. Use CI as the primary source of verification evidence. Run clause 5.8 at the release boundary, not every sprint. Define the release boundary explicitly in the software development plan so the team knows when internal iteration ends and medical device release begins. Trace every activity in the agile process back to a specific clause of EN 62304:2006+A1:2015 and, through the standard, to MDR Annex I Section 17. And cut activities that do not trace.

The anti-pattern is the "agile means no documentation" reading combined with the "compliance means lots of documentation" reflex, producing teams that either skip the standard entirely or build a parallel bureaucratic layer that burns runway. Neither is required. For the broader framework, see post 065.

Reality Check. Can your agile process survive an EN 62304:2006+A1:2015 audit?

  1. Does your software development plan name the agile cadence and explicitly map each sprint activity to a clause of EN 62304:2006+A1:2015?
  2. Do your requirements live in a structured, versioned artefact in the repository, not only as ticket titles or comments?
  3. Is the traceability from requirements to design to code to tests to risk items closed per story, or deferred to a future audit panic?
  4. Is your verification evidence produced automatically by CI, with logs retained, and not written by hand after the fact?
  5. Do you have a clearly defined release boundary where internal sprint increments end and clause 5.8 releases begin, documented in the software development plan?
  6. Are internal sprint increments deployed only to internal or staging environments, never directly to patient-facing production without running clause 5.8?
  7. Does your risk management under EN ISO 14971:2019+A11:2021 run continuously alongside sprint work, or as a retrospective exercise?
  8. Does your design review under EN ISO 13485:2016+A11:2021 clause 7.3 run at the release boundary, not at every sprint?
  9. Can you produce, for any released version, a complete list of stories, requirements, design changes, test results, risk updates, and the release authorisation. All traceable from the release record?
  10. When your cadence or tooling changes, does the software development plan get updated, or does it describe a process the team no longer runs?

Any question you cannot answer with a clear yes is a gap the next audit will find. Closing the gap is a tooling and discipline exercise, not a methodology change. Agile stays; the evidence capture gets tighter.

Frequently Asked Questions

Is agile development allowed under EN 62304:2006+A1:2015? Yes. The standard is explicitly process-neutral and does not prescribe a lifecycle model. Agile, waterfall, V-model, spiral, and hybrid approaches all satisfy the standard if the required activities happen with documented evidence and closed traceability. The manufacturer documents the chosen lifecycle in the software development plan. Most Notified Bodies have audited many agile medical device software projects; the methodology is not the issue, the evidence discipline is.

Do I need to run design controls every sprint? No. Design controls under EN ISO 13485:2016+A11:2021 clause 7.3 close at the release boundary, not at every sprint. Multiple sprints of internal development activity roll up into one design review, one verification summary, one validation summary, and one release decision. The evidence is captured continuously across the sprints, and the review happens at the release boundary.

Can a continuous delivery pipeline work for medical device software? Continuous delivery at the internal cadence. Automated builds, automated tests, automated deployment to internal and staging environments. Is fully compatible with the standard. Continuous delivery directly to patient-facing production without running clause 5.8 between each deployment is not. The release activity has documented criteria that cannot be satisfied by pipeline automation alone; a named role authorises the release against those criteria.

How do requirements work in an agile medical device project? Requirements live as a structured, versioned artefact in the repository, not only as ticket titles. Each sprint story links to the requirement it implements, and the requirements document is updated per change. The agile team can use any requirements format the standard allows. Shall-statements, user stories with acceptance criteria, formal specifications. Provided the artefact is traceable, verifiable, and not reconstructed from memory at audit time.

Does EN 62304:2006+A1:2015 require a big design up front? No. The standard requires an architecture and a detailed design at the depth the software safety class demands, documented before the code it describes is released. It does not require the architecture to be complete before any coding starts. Agile architecture. Where the structure is established early and evolves through the sprints with documented updates. Is compatible with clause 5.3 and clause 5.4, provided the documentation reflects the current state at each release.

What about Class C software. Can it still be agile? Yes. Class C software requires the most rigour in the lifecycle activities, but it does not require a specific lifecycle model. A Class C agile project has more verification evidence per sprint, more thorough unit-level design, and more careful risk integration, but the agile cadence is still valid. The rigour scales with the class; the methodology does not change.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015. Medical device software. Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 13485:2016+A11:2021. Medical devices. Quality management systems. Requirements for regulatory purposes, clause 7.3 Design and development. Harmonised standard referenced for the QMS under MDR Article 10(9) and Annex IX.
  4. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on reconciling agile development practices with EN 62304:2006+A1:2015 and MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post. EN 62304:2006+A1:2015 and EN ISO 13485:2016+A11:2021 are harmonised tools that provide presumption of conformity with specific MDR obligations, not independent authorities. For startup-specific regulatory support on agile lifecycle implementation, release boundary design, and design control integration, Zechmeister Strategic Solutions is where this work is done in practice.