How does Agile/Scrum work with IEC 62304?
IEC 62304 §5 (development process) · FDA Agile guidance 2023
The short answer
IEC 62304 does not prescribe a development methodology. Agile and Scrum are fully compatible with IEC 62304 provided the required lifecycle activities are planned, executed, and documented within your sprint or increment structure. The standard defines what must happen — not how you organise your sprints.
Key principle: IEC 62304 is process-based, not method-based
IEC 62304 is output-oriented. It specifies that certain activities must occur (requirements specification, architecture, verification, etc.) and that certain records must exist. It does not care whether those activities happen in a waterfall sequence, in two-week sprints, or in any other format.
Mapping Agile artifacts to IEC 62304 requirements
| Agile artifact / event | IEC 62304 requirement it can satisfy |
|---|---|
| User Stories / Acceptance Criteria | Software Requirements Specification (SRS) — with traceability IDs added |
| Sprint Planning | Software Development Plan (work allocation, timelines) |
| Definition of Done (unit level) | Unit Verification criteria — must include pass criteria linked to requirements |
| Sprint Review / Demo | Integration testing evidence — record what was reviewed and results |
| Retrospective / process notes | Problem Resolution — systemic issues raised in retrospectives can feed problem records |
| Release / Sprint increment | Software Release Records — version, date, what was included, who approved |
| Backlog items (Bugs) | Problem Resolution Records — must have unique ID, severity, status, resolution |
Common challenges in Agile + IEC 62304
- Requirements traceability in backlog tools: Jira tickets and GitHub issues require custom fields or labels to carry requirement IDs that map to the SRS and traceability matrix
- Regression testing in CI/CD: Test results must be captured and linked to requirements — not just "build passes" status
- SOUP updates between sprints: Each SOUP version change requires re-evaluation and update of the SOUP register; this should be a standard backlog item type
- Change documentation for scope additions: New features added mid-development must follow the same change control and impact assessment as any other change (§8)
CI/CD integration
Automated test records produced by CI/CD pipelines (pytest, Jest, JUnit outputs) can serve as IEC 62304 verification records, provided:
- Test cases are linked to specific software requirements or design specifications
- Test results (pass/fail, date, version) are captured and stored (not ephemeral)
- The test runner and configuration are under version control (configuration management §8)
- Failed tests are tracked through the problem resolution process (§9)
What regulators actually check
A Notified Body auditor or FDA reviewer will not ask "did you use Scrum?" They will ask:
- For each software item, can you show that requirements were defined?
- Can you show that architecture decisions were documented?
- Can you show that unit verification was performed and recorded?
- Can you trace a requirement to the test that verified it?
- Are all bugs tracked and resolved through a documented process?
The evidence of these activities is what matters — not the methodology used to produce them.
Frequently asked questions
Can I use Kanban instead of Scrum?
Yes. IEC 62304 is methodology-neutral. Kanban, Scrum, SAFe, or any other Agile framework can be used. The requirement is that the lifecycle activities (requirements, architecture, verification, etc.) occur and are documented — not how they are organised.
Can GitHub issues serve as problem resolution records?
Yes, if they capture the required information: unique identifier (issue number), description of the problem, severity assessment, status, and resolution. GitHub issues with mandatory fields enforced through issue templates are a practical approach for many teams.
Do automated tests count as verification records?
Yes — if the test output is captured (not just reported as a CI status check), is linked to requirements, and is stored with the release baseline. A green CI badge is not sufficient — the actual test report must be archived.
When should requirements be frozen in an Agile process?
IEC 62304 does not require requirements to be frozen before development begins. What it requires is that when requirements change, the change is assessed for impact, the change is approved, and the change is reflected in updated SRS, architecture, and traceability records. Agile requirement evolution is fine — undocumented requirement drift is not.