---
title: Agile Development Under MDR: How to Reconcile Sprints with ISO 13485 Design Controls
description: ISO 13485 design controls can coexist with agile sprints if the design record is captured at the right cadence. Here is how.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: agile sprints ISO 13485 design controls
canonical_url: https://zechmeister-solutions.com/en/blog/agile-sprints-iso-13485-design-controls
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Agile Development Under MDR: How to Reconcile Sprints with ISO 13485 Design Controls

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **EN ISO 13485:2016+A11:2021 clause 7.3 design controls can coexist with agile sprints if the design record is captured at the right cadence. The reconciliation move is to separate two clocks: the sprint clock, which runs fast and produces incremental engineering work, and the design control clock, which runs at the release boundary and produces the clause 7.3 deliverables — design inputs, design outputs, design reviews, design verification, design validation, design transfer, and the design history file. Inputs are frozen per feature scope at the start of a sprint, outputs are captured at the end, reviews accumulate across sprints but close at the release boundary, and the design history file assembles continuously as a by-product of the engineering work rather than as a retroactive reconstruction. The clause 7.3 evidence lands in the technical documentation under MDR Annex II regardless of cadence.**

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

---

## TL;DR

- EN ISO 13485:2016+A11:2021 clause 7.3 prescribes design control activities and records, not a cadence. Sprints are compatible if the activities happen with documented evidence and the records close at the right boundary.
- Two clocks run in parallel. The sprint clock produces engineering increments. The design control clock produces the clause 7.3 records. They do not tick at the same rate.
- Design inputs freeze per feature scope at sprint planning. Design outputs are captured at sprint end. Design reviews accumulate across sprints and close at the release boundary with a single clause 7.3 review.
- The design history file assembles continuously as a by-product of the engineering work — artefacts live in the repository, not in a post-hoc binder.
- MDR Annex II technical documentation is the destination, and the clause 7.3 records feed into it directly. What a Notified Body reads at audit is the Annex II file, not the sprint board.
- Agile breaks clause 7.3 when design inputs live only in ticket titles, when reviews are deferred forever, when design transfer is an afterthought, or when the design history file is reconstructed at audit time.
- The fix is not slower sprints. It is capturing the design record at the point the engineering decision is made, in the repository, with traceability closed per feature.

---

## Why teams think clause 7.3 and sprints conflict

Every software team I meet that is running scrum or kanban hits the same wall the first time they read EN ISO 13485:2016+A11:2021 clause 7.3. The clause is written as a sequence — planning, inputs, outputs, review, verification, validation, transfer, changes — and it reads like a staged project with handoffs between phases. The team's sprints do not look like that. A sprint refines requirements, produces code, verifies the code, and closes with a demo, all inside two weeks, all from the same backlog. The clause 7.3 stages look like a gantt chart; the sprints look like a loop.

The apparent conflict is a misreading. Clause 7.3 does not prescribe a waterfall order. It prescribes that the activities exist, produce records, and close traceability. The sequence in the clause is the logical dependency order — you cannot review an output that has not been produced, and you cannot verify against inputs that do not exist — not a calendar order. A team running two-week sprints can satisfy every requirement of clause 7.3, and the reconciliation is mechanical once the two cadences are separated in the team's head.

For the full planning activity under clause 7.3, see post 290. For design inputs see post 291, design outputs post 292, reviews post 293, verification post 294, and validation post 295. This post is the cadence layer that sits on top of all six.

## Clause 7.3 versus sprint cadence — the two clocks

The reconciliation starts with a concept borrowed from the EN 62304:2006+A1:2015 reconciliation in post 397. Two clocks run in parallel, at different rates, and they are deliberately out of sync.

The sprint clock runs fast — typically one to four weeks. It produces engineering work. Stories are refined, implemented, tested, and integrated. The sprint is the unit of engineering progress and the cadence at which the team makes commitments and demonstrates results. Inside a sprint, the team updates whatever design artefacts the stories touch and closes traceability for the items picked up that sprint.

The design control clock runs slower — typically aligned to the release boundary, which might be quarterly, monthly, or tied to specific milestones. It produces the clause 7.3 records. One design review summary, one design verification summary, one design validation summary, and one design transfer record per release, not per sprint. The records cover the scope of the release, which is the sum of many sprints of engineering work.

The trap is trying to run the two clocks at the same rate. A team that runs a full clause 7.3 design review every two weeks burns out and produces shallow reviews. A team that defers all design activity until the release boundary produces a panicked reconstruction and misses traceability. The correct move is to run the engineering activities continuously and the formal records at the boundary, with the engineering artefacts feeding the formal records as a by-product.

## Design inputs at sprint start

Clause 7.3.3 requires design and development inputs that are appropriate, complete, unambiguous, verifiable, and not in conflict with each other. The agile reading is that inputs are captured at sprint planning for the stories being picked up, not at project start for the whole system.

At sprint planning, the team refines the stories from the backlog into design inputs that satisfy clause 7.3.3. The input for a story is not the story title — it is the structured specification the story points to. What the software shall do. Under what conditions. To what performance. Against which risk items. Linked to the user need or regulatory requirement it serves. The specification lives in the repository, versioned with the code, and the ticket references it.

The freeze is per feature scope, not per system. When a story is picked into the sprint, the design inputs for that story are frozen at the point of commitment. Changes discovered during the sprint go through the clause 7.3.9 change control path — a new input, a change record, a traceability update — not an undocumented drift inside the sprint.

Teams that run inputs this way find that sprint planning becomes the clause 7.3.3 activity, which means the activity happens every two weeks, continuously, in the place where the engineering decision is actually made. The team does not run a separate "requirements session" outside the sprint; the sprint planning is the session, with the artefact discipline built in.

## Design outputs at sprint end

Clause 7.3.4 requires design and development outputs that meet the input requirements, provide information for purchasing and production, contain or reference acceptance criteria, and specify characteristics essential for safe and proper use. For software, the outputs are the architecture and detailed design documents, the source code, the build artefacts, and the test specifications. For hardware-software combinations, add the drawings, bill of materials, manufacturing instructions, and labelling.

At sprint end, the outputs touched during the sprint are updated in the repository. The architecture document reflects the new modules. The detailed design reflects the new components. The test specifications reflect the new test cases. The bill of materials reflects the new parts. The updates are reviewed as part of the normal pull-request process, not in a separate document-control ceremony.

The output is captured at the point the engineering work is done, not reconstructed at the release boundary. This is the single most important discipline move. A team that captures outputs continuously has a design history file that assembles itself. A team that defers output capture to a future documentation sprint has a design history file that is fiction by the time it is written.

The acceptance criteria embedded in clause 7.3.4 map naturally to agile story acceptance criteria. The clause requires that outputs contain or reference acceptance criteria; the agile story already has them. The move is to make sure the story's acceptance criteria are the actual verification criteria, linked to the test that runs against them, and retained as part of the design record.

## Review cadence — continuous engineering, formal review at the boundary

Clause 7.3.5 requires systematic reviews of design and development at suitable stages, with participants from functions concerned with the stage being reviewed, and with records maintained. The agile reading is that reviews run at two cadences — continuous engineering review during sprints, and formal clause 7.3 design review at the release boundary.

Continuous engineering review happens inside the sprint. Pull requests are reviewed by peers. Architecture changes are discussed in team sessions. Risk items are revisited when the code that touches them changes. These reviews are real, produce records (pull request discussions, meeting notes, updated risk entries), and cover the engineering substance. They are not, however, the clause 7.3.5 formal design review.

The clause 7.3.5 formal review runs at the release boundary. It is scheduled, attended by the named functions (engineering, quality, regulatory, clinical, risk, PRRC as appropriate), minuted, and produces a written decision. The input to the formal review is the accumulated engineering work across the sprints — the updated design artefacts, the verification results, the risk file state, the anomaly list, the traceability matrix. The formal review does not re-do the sprint reviews. It evaluates the release readiness of the accumulated work against the design inputs and the regulatory obligations.

Two cadences, one continuous engineering review layer and one formal clause 7.3.5 review at the boundary. Neither replaces the other. Teams that run only the continuous layer fail audit because there is no named clause 7.3.5 record. Teams that run only the formal layer waste sprint time on ceremony that does not catch the issues the engineering review catches every day.

## Design history file assembly — continuous, not retroactive

Clause 7.3 is silent on the term "design history file" — it is an FDA term — but the equivalent under EN ISO 13485:2016+A11:2021 is the set of design and development records maintained under clauses 4.2 and 7.3. Under MDR Annex II, this feeds the technical documentation the Notified Body will read. Whatever you call it, it is the record of the design process across the product's life, and under agile it has to assemble continuously.

The assembly rule is simple: every artefact lives in the repository, versioned with the code, and the release boundary produces a release record that points to the state of every artefact at that version. The release record is the index. Point to it, pull the repository at the release tag, and you have the design history file for that release. No parallel binder. No retroactive assembly.

What lives in the repository: the software development plan, the requirements specification, the architecture document, the detailed design document, the risk management file, the verification protocols and results, the validation protocols and results, the design review minutes, the release records, the change records, and the traceability matrix. Pull requests link code changes to the relevant artefacts. The CI pipeline produces the verification evidence automatically and retains it as a build artefact linked to the commit.

When the Notified Body asks for the design history file at audit, the answer is not a document. It is the release tag and the index that points into the repository. Every artefact is reachable, versioned, and traceable. The team did not spend the week before the audit reconstructing it.

## What breaks in agile — failure modes under clause 7.3

The compatibility is real, but agile implementations fail clause 7.3 audits in predictable ways.

Design inputs that live only in ticket titles. A story titled "add alerting" is not a design input. The input is the specification the story points to. Teams that skip this layer have a requirements source that is the concatenation of every ticket title, not traceable, not verifiable, not defensible.

Design outputs that are updated only when someone remembers. The architecture drifts. The detailed design drifts. The bill of materials drifts. By release time the artefacts describe a system that no longer exists. The fix is to treat artefact updates as part of the story acceptance criteria — the story is not done until the affected artefacts are updated.

Design reviews deferred forever. The team intends to run a formal clause 7.3.5 review at the release boundary and then keeps pushing the boundary. The formal review never happens and the release ships anyway. The fix is to tie the release decision to the formal review output — no review, no release.

Design transfer treated as an afterthought. Clause 7.3.7 requires that design outputs be verified against production capabilities before release to production. Agile teams that ship software-only devices sometimes skip transfer because "production" is a deployment. It still is a transfer — from the development environment to the validated production environment — and the clause still applies.

Design history file reconstructed at audit time. The team spends the two weeks before the audit assembling a binder from git history, memory, and fragments. The binder is fiction. The auditor asks one question that is not in the binder and the whole thing unravels. The fix is continuous assembly in the repository — there is nothing to reconstruct because nothing was ever missing.

## Common mistakes teams make

- Running a parallel "design controls" track that duplicates the engineering work and drifts out of sync with it.
- Treating each sprint as a clause 7.3 release and burning out on ceremony.
- Freezing design inputs at the project level instead of per feature scope, then resisting every change because it breaks the frozen plan.
- Letting pull request discussions substitute for the formal clause 7.3.5 design review record.
- Deferring traceability closure to the release boundary and arriving there with weeks of unmatched links.
- Keeping the design history file as a parallel binder instead of as artefacts in the repository.
- Confusing the definition of "done" with clause 7.3 release — a done story is not a released medical device.
- Losing track of which release a given design review covered, so the scope of the review is unclear at audit.

## The Subtract to Ship angle

The clause 7.3-to-sprint reconciliation is a subtraction exercise. The default reaction is to add a parallel design controls layer — a second team, a second toolchain, a second set of documents — that sits alongside the engineering work. That layer is waste. The engineering work already produces nearly everything clause 7.3 requires; the subtraction move is to make that work produce the records in the right place rather than duplicating it in a separate system.

The cuts that matter. Cut the parallel documentation track. Artefacts live in the repo with the code. Cut the per-sprint formal design review. Formal clause 7.3.5 runs at the release boundary. Cut the retroactive design history file assembly. The file assembles itself if the artefacts are in the repo. Cut the freeze-the-whole-system input model. Inputs freeze per feature at sprint planning under change control. Cut the "we'll close traceability at the end" deferral. Traceability closes per story. Cut the ticket-title-as-requirement pattern. Requirements live as structured artefacts the tickets point to.

Every activity that survives the cut traces to a specific sub-clause of clause 7.3 and, through clause 7.3, to MDR Annex II. The team runs a lean design control system because the engineering work is doing the load-bearing part. For the broader framework, see post 065.

## Reality Check — Can your sprints survive an EN ISO 13485:2016+A11:2021 clause 7.3 audit?

1. Does every story in your sprint point to a structured design input artefact in the repository, or do inputs live only in ticket titles?
2. Are design outputs updated as part of story acceptance criteria, so the architecture and detailed design documents never drift more than one sprint out of date?
3. Do you run a formal clause 7.3.5 design review at the release boundary, with named participants, minutes, and a written release recommendation?
4. Is your design history file an index into the repository at a release tag, or a parallel binder maintained outside the engineering workflow?
5. Have you defined the release boundary explicitly, and do the team and the design controls system agree on where it is?
6. Does traceability — inputs to outputs to verification to validation to risk — close per story, not per audit?
7. When a design input changes mid-sprint, does a clause 7.3.9 change record get created, or does the change happen silently?
8. Can you produce, for any released version, the exact state of the requirements, design, verification, validation, risk file, and review records at that version?
9. Does your design transfer activity under clause 7.3.7 have a documented record, even for software-only releases?
10. Does what a Notified Body sees in your MDR Annex II technical documentation match what the sprint team actually did, or does it describe a process that no longer runs?

Any answer that is not a clear yes is a gap. Closing it is a discipline and tooling fix, not a methodology change.

## Frequently Asked Questions

**Do EN ISO 13485:2016+A11:2021 clause 7.3 design controls require waterfall development?**
No. Clause 7.3 prescribes activities and records, not a lifecycle model. Agile, waterfall, and hybrid approaches all satisfy the clause if the activities happen with documented evidence and closed traceability. The sequence in the clause is the logical dependency order, not a calendar order, and a team running sprints can satisfy every sub-clause.

**At what cadence should I run a clause 7.3.5 formal design review in an agile project?**
At the release boundary, not every sprint. One formal review per release, covering the accumulated engineering work from the sprints in scope, with named participants from engineering, quality, regulatory, clinical, risk, and PRRC as appropriate. Continuous engineering review — pull requests, architecture discussions, peer review — runs alongside but does not replace the formal clause 7.3.5 record.

**How do I capture design inputs when requirements evolve during sprints?**
Freeze inputs per feature scope at sprint planning, not per system at project start. Changes discovered mid-sprint go through clause 7.3.9 change control — a new input entry, a change record, an updated traceability link — in the same artefact the story points to. The result is a requirements specification that evolves under control, not a frozen document that the team resents and ignores.

**Where does the design history file live in an agile project?**
In the repository, as versioned artefacts, with a release record that indexes the state at each release tag. Requirements, architecture, design, risk file, verification results, validation results, review minutes, and release records are all markdown or structured text alongside the code. At audit time, the release tag is the index — no parallel binder exists or needs to exist.

**How does clause 7.3 feed MDR Annex II technical documentation?**
The clause 7.3 records are the backbone of the design and manufacturing information required by MDR Annex II, section 3. Design inputs map to the device description and specifications. Design outputs map to the design and manufacturing information. Verification and validation records map to the pre-clinical and clinical evaluation. The Annex II file is not a separate document — it is a view of the design record organised for the Notified Body reviewer.

**Is continuous delivery compatible with clause 7.3?**
Continuous delivery at the internal cadence is compatible. Continuous delivery directly to patient-facing production without running the clause 7.3 release activity between deployments is not. The release decision is a documented activity with named authorisation; pipeline automation alone cannot satisfy it. The move is to automate everything up to the release boundary and require the authorised release activity to cross it.

## Related reading

- [MDR Design and Development Planning: The ISO 13485 Clause 7.3.2 Startup Guide](/blog/mdr-design-development-planning) — the planning activity that names the agile cadence and maps it to clause 7.3.
- [Design Input Requirements for MedTech Startups](/blog/design-input-requirements-medtech) — the clause 7.3.3 activity the sprint freezes per feature scope.
- [Design Output Requirements for MedTech Startups](/blog/design-output-requirements-medtech) — the clause 7.3.4 activity that captures at sprint end.
- [MDR Design Reviews Under ISO 13485 for Startups](/blog/mdr-design-reviews-iso-13485-startup) — the clause 7.3.5 activity that closes at the release boundary.
- [MDR Design Verification Under ISO 13485](/blog/mdr-design-verification-iso-13485) — the clause 7.3.6 activity that CI operationalises.
- [MDR Design Validation Under ISO 13485](/blog/mdr-design-validation-iso-13485) — the clause 7.3.7 activity at the release boundary.
- [Agile Development Under MDR: How to Reconcile Agile with IEC 62304 Requirements](/blog/agile-development-mdr-iec-62304) — the companion reconciliation for the software lifecycle standard.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar this post applies to clause 7.3 reconciliation.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex II — Technical Documentation. Official Journal L 117, 5.5.2017.
2. 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.
3. 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.

---

*This post is a category-7 spoke in the Subtract to Ship: MDR blog, focused on reconciling agile sprint cadences with EN ISO 13485:2016+A11:2021 clause 7.3 design controls for MDR Annex II technical documentation. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN ISO 13485:2016+A11:2021 and EN 62304:2006+A1:2015 are harmonised tools that provide presumption of conformity with specific MDR obligations, not independent authorities. For startup-specific regulatory support on design control integration with agile engineering practice, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*