ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
IEC 62304 agile development is possible, and many medical device software teams already do it, but only when every activity the standard requires still happens, just spread across sprints instead of stacked into phases. The mistake that sinks teams is assuming “working software over comprehensive documentation” excuses the plan, the traceability and the verification records that an auditor will ask for.
This guide explains how the iteration layers map to the standard’s lifecycle, what to put in your definition of done, how to handle releases and change, and where the guidance in AAMI TIR45 helps. For the documents themselves, see our IEC 62304 documentation requirements.
Free gap assessment
How much of ISO 13485 could you evidence today?
Score clauses 4 to 8, free, with the FDA QMSR and EU MDR duties kept separate so you can see what is the standard and what is the regulator.
Run the free ISO 13485 gap assessment → or View premium report sample
Yes. The Johner Institute summarises the position of AAMI TIR45, the technical information report on agile practices in medical device software, as saying that it is possible to develop software for medical devices with agile practices while complying with regulatory requirements. The standard prescribes activities and outputs, not a delivery model, so it does not require a waterfall. What it does require is that development is planned, requirements are defined, architecture and detailed design are done, units are verified, integration and system testing are performed, and release is controlled, all according to the software safety class.
TIR45 is guidance, not a regulation. Commentary describes it as widely referenced by regulators and notified bodies as a way to show agile methods fit the standard, but check what your own notified body or reviewer expects. A second edition of the report, published in 2023, expands on documentation approaches, streamlined approvals and the integration of cybersecurity, risk management, validation and usability into agile frameworks, according to AAMI’s description of its training course.
The Johner Institute describes four layers of iteration in TIR45: project, release, increment and story. The activities that IEC 62304 requires do not disappear, they are distributed across the layers.
| Layer | Typical agile activity | IEC 62304 activities covered |
|---|---|---|
| Project | Vision, backlog, high-level architecture | Development planning, software requirements, coarse architecture |
| Release | Release planning, integration and system testing | Integration testing, system testing, release |
| Increment or sprint | Sprint planning, review, retrospective | Detailed design, implementation, unit verification |
| Story | Implementing one user story | Requirement refinement, coding, testing against acceptance criteria |
The safety classification still drives how much rigour each activity needs. A story that changes a class C item carries more verification and documentation than one that touches a class A item. Our guide to IEC 62304 software safety classification explains how to assign the class.
A clear definition of done is where regulatory needs meet the daily routine. Build the documentation and traceability requirements into it, so that no story is closed without the evidence that an auditor would look for. A useful definition includes the following items.
User stories can serve as design inputs when they come with acceptance criteria that include non-functional aspects such as performance, safety behaviour and error handling. A story that reads “as a nurse I want an alarm” is not testable until the acceptance criteria say what triggers the alarm, what it sounds like and what happens if it is acknowledged. Make the criteria specific enough to write a test from.
Agile teams release often, but a regulated product needs some releases to be formal. TIR45, as summarised by the Johner Institute, treats release boundaries as checkpoints for design reviews and consolidated documentation, and it suggests deciding in your quality management system which increment or release endings count as formal reviews. That gives auditors a clear point at which the plan, requirements, architecture, test results and risk file come together and are approved. Between those checkpoints the team can work quickly, with the definition of done keeping the evidence current. Our note on IEC 62304 and ISO 13485 shows how the quality system supports this.
Modern tools can generate much of the traceability. Link requirements to stories, stories to code changes, code to tests and tests to results, and produce a matrix at each formal release. Make sure the tools are validated for their use in line with your quality system, that records are protected against unintended change and that you can reproduce the state of a release later. Where you use third-party libraries or frameworks, remember the software of unknown provenance obligations, covered in our guide to IEC 62304 SOUP.
Frequent change is the central risk of any fast process, so make change control lightweight but real. Each change should be identified, assessed for its effect on safety, requirements and existing verification, approved by a person with the authority to do so and traceable to the code and tests that implement it. In practice, that can be a pull request template with mandatory fields, a required reviewer for changes that touch safety-related items and an automated check that blocks a merge without a linked ticket. The aim is proportion: a cosmetic change to a class A screen needs little ceremony, while a change to an alarm algorithm needs an impact analysis and regression tests.
Automated tests are the engine of IEC 62304 agile development, since they let a team change code often without losing confidence. Treat the automated test suite as a verification asset: review it, control its versions, record what it covers and archive the results for each formal release. Where automated coverage is thin, add manual regression for the affected areas, and record the reasoning so that a reviewer can see the decisions were deliberate.
A team builds an infusion pump companion app classified as class B. Its development plan defines two-week sprints, quarterly formal releases and a definition of done that includes trace links and risk review. In a sprint, a story adds a low-battery warning. The acceptance criteria cover the threshold, the message and the alarm priority. The risk engineer reviews the story and adds a control to the risk file. The developer implements, a peer reviews, automated tests run, and the results are stored with the story. At the quarterly release, the team generates the trace matrix, runs system tests, holds a formal review and signs off the release. The example is illustrative only.
Auditors will ask to see the plan that defines the agile process, evidence that teams follow it and a complete trace from requirements to verification for a sampled feature. Prepare a short description of how sprints, releases and formal reviews fit the standard, so the auditor does not have to piece it together from tickets. Keep sample stories ready as examples, along with the review records and the risk links. Explain your approach to change control clearly, because auditors are often most concerned that fast iteration has not weakened it.
The standard’s outputs still need a home: a software development plan, requirements and architecture documents, a test plan, a trace matrix, a release record and a problem resolution procedure. The IEC 62304 Toolkit includes templates for these, which you can adapt to an agile workflow. Read the Johner Institute’s summary of TIR45 for further detail, and look at IEC 62304 Edition 2 for what is changing in the standard.
Yes, provided all required activities and outputs are performed and documented, in a way that matches your software safety class.
A technical information report that gives guidance on using agile practices in medical device software development while meeting regulatory requirements. It is guidance, not a mandatory standard.
They can serve as design inputs if they carry acceptance criteria that include non-functional aspects, and if they are traceable and controlled.
You decide in your quality system, but many teams treat release boundaries as formal checkpoints for design review and consolidated documentation.
September 30, 2026
September 30, 2026
