EN 62366-1:2015+A1:2020 is a process standard, not a waterfall standard. It maps cleanly onto sprint-based development if formative evaluations run continuously inside sprints, the risk file is kept in lockstep with the interface, and a hard freeze is declared before summative evaluation. Agile does not exempt a team from usability engineering. Agile done badly lets a team ship features faster than it documents use error. Agile done well turns every sprint into a formative loop and leaves summative as the final audit-ready artefact.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN 62366-1:2015+A1:2020 defines a usability engineering process: use specification, user interface specification, known use problems analysis, hazard-related use scenarios, formative evaluation, and summative evaluation. None of these require a waterfall cadence.
  • Formative evaluation belongs inside sprints. It is cheap, iterative, and its purpose is to expose use error while the cost of change is still low.
  • Summative evaluation must happen on a frozen user interface. The design baseline for summative is a controlled configuration, documented and version locked.
  • The usability risk file under EN ISO 14971:2019+A11:2021 is updated every sprint. A risk file that only gets touched before audits is an auditor flag.
  • EN ISO 13485:2016+A11:2021 clause 7.3 on design and development does not specify a cadence. It specifies controls. Agile satisfies those controls when every sprint produces documented design inputs, outputs, verification, and review records.
  • EN 62304:2006+A1:2015 for software lifecycle and EN 62366-1 for usability must be planned together, not in separate tracks.

Why this matters

Felix has coached teams that ran two-week sprints on the software and a separate, half-forgotten usability workstream with a single summative evaluation slotted six months before submission. When that evaluation surfaced use errors, the entire sprint backlog was blocked while engineers rewrote flows the team had considered finished. Nobody had failed to work hard. The team had failed to integrate.

Tibor has audited the downstream version of the same story. A notified body review finds a summative evaluation run on a build that is three releases behind the current master. The team explains that the software is iterating too fast for usability to keep up. That explanation is an audit finding, not an excuse. The standard does not accept "we were moving too fast" as a control.

Agile and EN 62366-1 are compatible. The confusion comes from reading EN 62366-1 as if it prescribed a project plan. It does not. It prescribes a process whose artefacts must exist, be consistent, and be traceable. That is achievable inside sprints if the team treats usability as a product discipline rather than a documentation task.

What MDR actually says

MDR Annex I does not mention agile or waterfall. It mentions outcomes.

Annex I GSPR §5 requires the manufacturer to reduce risks linked to the ergonomic features of the device and to the use environment, as far as possible. Whether the team reaches that reduction through sprints, stage gates, or any other cadence is a manufacturer choice.

Annex I GSPR §22 requires devices intended for lay users to be designed and manufactured to perform appropriately given the skills and means available to those users. Same point: outcomes, not methodologies.

The harmonised standard EN 62366-1:2015+A1:2020 defines nine process steps, from preparation of the use specification through the summative evaluation. The standard uses the words "process" and "activities". It does not use the word "phase" in a prescriptive sense. Every activity can be run iteratively. Every artefact can be versioned.

EN ISO 13485:2016+A11:2021 clause 7.3 places the design and development process under documented control. It requires planning, inputs, outputs, review, verification, validation, transfer, and change control. An agile team that runs all of these per sprint and captures the records satisfies the clause. An agile team that skips records because "we have standups" does not.

EN 62304:2006+A1:2015 for the software lifecycle lives alongside EN 62366-1. When the device is software or contains software, use error handling and software item development must share a coherent plan. The usability engineering file and the software development plan reference each other.

EN ISO 14971:2019+A11:2021 ties the usability work to risk management. Every use error identified in formative evaluation updates the risk file. Every risk control introduced to mitigate a use error updates the user interface specification. This is a two-way link, not a one-way handoff.

A worked example

A startup is building a Class IIa digital therapeutics application. Five engineers. Two-week sprints. The device is a mobile application accompanied by a Bluetooth sensor. Target markets are Germany, Austria, and the Netherlands. The team plans for notified body submission twelve months after project start.

The usability engineering file is opened on day one. The use specification is a living document under version control in the same repository that holds the code, with separate branches rejected as a matter of policy. The user interface specification is a structured document that references the exact UI component library used by the application.

Sprint structure:

  • Sprint 0. The team prepares the use specification, initial user interface specification, known use problems analysis drawing on published literature, and a first draft of hazard-related use scenarios. The usability engineer is on the team, not a contractor on call.
  • Sprint 1 onward. Every sprint contains at least one formative evaluation activity. Not always a user test. Sometimes a heuristic review, sometimes a cognitive walkthrough, sometimes a moderated session with two external users recruited from a standing panel. Clause 5.7 of EN 62366-1 explicitly allows formative methods to vary as long as they produce evidence that feeds the iteration.
  • End of every sprint. The risk file under EN ISO 14971:2019+A11:2021 is updated. Any new use error found in the formative session is logged. Any mitigation added to the UI is cross-referenced. The user interface specification is updated in the same commit that changes the code. The reviewer on the pull request is required to confirm both artefacts are consistent.
  • Every three sprints. Design review under EN ISO 13485:2016+A11:2021 clause 7.3.4. The usability engineer presents the delta: new risks, resolved risks, formative evidence. Findings are recorded.
  • Sprint 18 to 20. The team declares a usability freeze. The user interface specification is tagged as release candidate. No unrelated UI changes are allowed in the repository without a formal change request.
  • Sprint 21. Summative evaluation under EN 62366-1 clause 5.9. Conducted on the frozen build with representative users from the named markets. Test report prepared. Residual use error assessed against the acceptance criteria in the usability engineering plan.
  • Sprint 22. Any corrective design change triggers re-testing of the affected scenarios. Clause 5.9 of EN 62366-1 is explicit that corrective changes require re-evaluation of the affected tasks.

The result is a usability engineering file that looks like any other EN 62366-1 deliverable. A notified body reading it cannot tell it was produced in sprints. That is the point. The cadence is invisible to the auditor because the artefacts and the traceability are in place.

The Subtract to Ship playbook

The playbook is short because agile is a tool, not a philosophy.

Step 1. Put the usability engineer on the team. Not a reviewer. Not a consultant on call. Someone inside the daily stand-up whose job is to push formative work forward every sprint.

Step 2. Treat the usability engineering file as code. Version control, pull requests, reviewer checks. The user interface specification is a document, but it is edited with the same rigour as source code.

Step 3. Schedule formative methods, not formative events. Heuristic reviews, cognitive walkthroughs, moderated sessions, think-aloud protocols, and task analyses are all acceptable formative methods under EN 62366-1:2015+A1:2020. Pick the cheapest method that would surface the risk at hand.

Step 4. Update the risk file at the end of every sprint. Not at the end of every quarter. Not before audits. Every sprint. EN ISO 14971:2019+A11:2021 requires ongoing risk management. Ongoing is not a synonym for eventual.

Step 5. Use design review as the checkpoint that agile ceremonies miss. Sprint retrospectives are not design reviews. Clause 7.3.4 of EN ISO 13485:2016+A11:2021 requires documented design reviews with participants from all relevant functions. Schedule them on a cadence the regulation will accept, not a cadence the team feels like.

Step 6. Declare a hard usability freeze before summative. Communicate it. Enforce it. Pull requests that touch the UI during freeze require a signed change request. Summative on a drifting build is not summative.

Step 7. Plan software and usability together. EN 62304:2006+A1:2015 and EN 62366-1:2015+A1:2020 are not two separate worlds. The software development plan and the usability engineering plan reference each other, and integration points are explicit.

Step 8. Budget for re-testing after summative corrections. A team that assumes the first summative will pass has not done this before. Tibor has reviewed many that did not.

Reality Check

  1. Is there a usability engineer on the sprint team, attending daily stand-ups, or is usability assigned to someone outside the delivery cycle?
  2. Can you point to a formative evaluation activity in every completed sprint over the last three months?
  3. When was the risk file under EN ISO 14971:2019+A11:2021 last updated, and does that date match the last UI change in the repository?
  4. Does your user interface specification live under version control with the code, or does it sit in a separate document that nobody updates?
  5. Have you declared a usability freeze date on the roadmap, and does the team understand what a freeze means?
  6. Are design reviews under EN ISO 13485:2016+A11:2021 clause 7.3.4 scheduled on a regulation-acceptable cadence, or are retrospectives substituting for reviews?
  7. Is the summative evaluation planned on a tagged build that will not receive further UI commits until the report is accepted?
  8. If corrective changes are required after summative, is there budget and schedule for re-testing the affected scenarios?

Frequently Asked Questions

Can we really do formative evaluations every sprint? Yes, if formative is understood broadly. EN 62366-1:2015+A1:2020 does not require a full laboratory user test every sprint. A cognitive walkthrough with two recruited users, a heuristic review against the known use problems list, or a task analysis on a new flow all count. Pick the method that fits the sprint content.

How many summative evaluations do we need? One, on a frozen build that represents the final device. Corrective changes after summative may require partial re-evaluation of the affected scenarios, not a full re-run, provided the corrections are bounded and documented.

Does agile contradict EN ISO 13485 clause 7.3? No. Clause 7.3 requires planning, inputs, outputs, review, verification, validation, and change control. Agile teams satisfy these through per-sprint records. The standard is indifferent to whether the cadence is two weeks or six months, as long as the records exist.

What if the UI keeps changing after summative? Then the summative evaluation is stale. Either freeze the UI and re-run affected scenarios, or postpone summative. Shipping with a summative run on an obsolete build is a notified body finding Tibor has written more than once.

Do we need a separate formative test with real users every sprint? No. Formative methods range from heuristic review to moderated user tests. A good usability engineer varies the method. What must be continuous is the evidence, not the cost.

Where does use error sit in the product backlog? In the same backlog as other engineering work. A use error found in formative evaluation becomes a ticket with the same lifecycle as a bug, the difference being that closing it also updates the risk file.

Sources

  1. Regulation (EU) 2017/745 on medical devices. Annex I, §5 and §22.
  2. EN 62366-1:2015+A1:2020, Medical devices – Application of usability engineering to medical devices.
  3. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices.
  4. EN ISO 13485:2016+A11:2021, Medical devices – Quality management systems, clause 7.3 Design and development.
  5. EN 62304:2006+A1:2015, Medical device software – Software life cycle processes.