Scrum in medical device development might seem like an unusual combination. Medical device development is one of the last places you would want someone telling a team to move fast and figure things out as they go. The consequences of getting something wrong can be serious. Patients can get hurt, products are regulated, risks need to be actively managed, and designs may require extensive verification and validation. Organizations also need to maintain the documentation, records, and traceability necessary to demonstrate that they followed their quality system and applicable regulatory requirements.
So where does Scrum fit into medical device development?
The answer isn’t that Scrum provides a way around these constraints. It doesn’t. Using Scrum doesn’t make regulatory requirements disappear, and being Agile isn’t an excuse to postpone safety, testing, documentation, or quality work until somebody has time to deal with it.
The opportunity is almost the opposite. Scrum can help medical device organizations develop products in smaller batches, confront important risks and uncertainties earlier, and learn from actual results before making increasingly expensive commitments. Safety, quality, compliance, and the work necessary to create appropriate evidence can remain part of product development rather than becoming a large batch of work waiting at the end.
The important distinction is between reducing the batch size of product development and reducing the rigor with which the product is developed. Those are not the same thing.
Scrum Doesn’t Replace Medical Device Regulations
Let’s get the most important misconception out of the way first. Scrum is not a regulatory framework, quality management system, risk management process, or medical device development standard. It is a framework for developing complex products.
A medical device manufacturer still has to understand and satisfy the requirements that apply to its particular product and market.
In the United States, for example, FDA’s Quality Management System Regulation, or QMSR, became effective on February 2, 2026, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. Depending on the product, market, and nature of the device, numerous other regulations, standards, guidance documents, and organizational quality requirements may also apply.
Scrum doesn’t tell an organization which of those requirements apply. It doesn’t determine whether a risk is acceptable, prescribe a verification protocol, or declare a medical device safe. Those responsibilities don’t disappear because a Scrum Team exists.
What Scrum does give us is a way to manage complex product development when we know we can’t perfectly predict everything that is going to happen before development begins. Instead of creating a massive plan based on what we think will happen and measuring success by how closely reality follows that plan, Scrum gives us frequent opportunities to build something, inspect the results, learn from what happened, and adapt what we do next.
For a medical device company, that distinction matters.
The Problem Isn’t the Rigor. It’s the Batch Size.
Consider a simplified medical device development process. An organization might begin by defining requirements, move into design, build the product, integrate its components, perform verification and validation activities, complete the necessary documentation, and eventually move through whatever regulatory and commercialization processes apply.
There isn’t anything inherently wrong with those activities. Many of them may be necessary. The problem appears when we assume they need to happen in enormous sequential batches.
Imagine spending six months developing detailed requirements for an entire device, followed by another six months creating detailed designs. Engineering then spends months building individual components before enough of the system exists to integrate them and seriously test whether some of the organization’s most important assumptions were correct.
Eventually, reality gets a vote.
Maybe a mechanical design doesn’t behave as expected under real-world conditions. Perhaps a sensor isn’t as reliable as early analysis suggested. Maybe clinicians have difficulty using an interface that looked perfectly reasonable in a specification. Two subsystems might work independently but behave differently when they’re finally integrated. A safety control might mitigate one risk while introducing an unexpected usability problem somewhere else.
The organization has learned something extremely valuable. The problem is that it learned it eighteen months after making the decision.
Scrum in medical device development gives us an opportunity to shorten that feedback loop without reducing the rigor required to build the product.
Use the Product Backlog to Identify Important Problems Worth Solving
One of the most useful ways to think about a Product Backlog is not as a giant inventory of tasks people need to complete, but as an ordered list representing what is needed to improve the product.
For a medical device, that can lead to a very different conversation about the work.
Imagine we’re developing an infusion pump. Instead of immediately decomposing the entire product into hundreds or thousands of implementation tasks, we might identify important problems the product needs to solve. We need to prevent a clinician from accidentally entering a dangerously high dosage. We need to detect an occluded IV line. We need to make the device’s power state unmistakable. We need clinicians to configure common infusions efficiently. We may also need maintenance personnel to recognize when a pump requires service before it returns to clinical use.
Those statements aren’t intended to replace formal requirements or risk-management artifacts. The organization may still need those things. They represent a different level of conversation: what problems are important enough that we should spend time and money solving them?
Once we begin looking at the Product Backlog this way, ordering becomes much more interesting. Customer demand may influence what we work on, but so can patient safety, technical uncertainty, regulatory considerations, dependencies, cost, learning, and risk.
That means the most important Product Backlog item isn’t necessarily the feature that generates the most revenue or the one that a customer asked for most recently. Sometimes the most valuable thing we can do is find out whether a critical assumption is wrong.
Risk Can Help Determine What We Work on First
Suppose a medical device depends on a particular sensing technology. The entire product concept assumes that this sensor can produce sufficiently reliable results under the conditions in which the device will actually operate, but the engineering team isn’t completely certain that it can.
There may be dozens of easier things the team could work on first. They could build administrative screens, refine enclosure designs, implement secondary functionality, or spend months elaborating requirements for features that will eventually be needed. But if the sensing technology represents a fundamental risk to the viability of the product, why would we deliberately postpone learning about it?
That problem can move toward the top of the Product Backlog. The team can determine what it would need to build or test to learn something meaningful about the technology. Perhaps that means constructing a prototype rather than a production-ready component. Maybe it means integrating the sensor with enough of the system to test its behavior under realistic conditions. The team can gather information, inspect the results, and use what it learns to decide what should happen next.
The objective isn’t simply to finish a feature quickly. The objective is to shorten the distance between making an important assumption and obtaining evidence about whether that assumption is correct.
This is one of the places where Scrum can be especially powerful in medical device development. Instead of treating risk management as something separate from product development, what we learn about risk can influence the order in which we attack problems.
Small-Batch Development Does Not Mean Lowering the Bar
This is where the Definition of Done becomes especially important.
Suppose our Scrum Team decides to address the problem of preventing clinicians from accidentally entering a dangerously high dosage. The team designs a solution, implements it, integrates the necessary hardware and software, and demonstrates that it appears to work.
Can we call it Done?
That depends on what Done means in that organization and for that product.
Depending on the device, development stage, quality management system, and applicable requirements, completing that work might involve design documentation, applicable risk-management activities, traceability, reviews, implementation, component testing, integration testing, cybersecurity considerations, usability considerations, or updates to other technical documentation.
That isn’t intended to be a universal medical device compliance checklist. It shouldn’t be. Different products, organizations, markets, risks, and stages of development have different requirements.
The larger point is that the team shouldn’t get to call something Done simply because the engineering work appears to function. If additional work is required for the Increment to meet the organization’s quality standards, that work needs to be visible.
The Definition of Done Can Help Prevent Compliance Debt
One of the worst patterns a regulated product organization can create is a large inventory of work that everyone informally considers “finished” even though substantial work remains before it actually meets the organization’s standards.
An engineer finishes the implementation, demonstrates that it works, and the feature gets marked complete. Meanwhile, verification work remains unfinished, traceability hasn’t been updated, required reviews haven’t happened, risk-management artifacts are behind, and documentation will supposedly be cleaned up later.
The organization looks like it’s moving quickly because a lot of things are being called finished. In reality, it is accumulating unfinished work.
This is one reason the Definition of Done can be so valuable. It creates transparency around the quality measures required for an Increment. If applicable safety, quality, documentation, testing, or compliance activities are necessary for the work to meet that standard, they can be incorporated into the Definition of Done as appropriate.
That changes how we measure progress.
Suppose implementing a capability takes two days, but completing all the work necessary for it to meet the Definition of Done takes eight days. That’s not a two-day piece of work with six days of annoying overhead attached to it. It’s eight days of product development.
Calling it finished after two days doesn’t make the organization faster. It just hides six days of unfinished work.
For regulated product development, that distinction is enormously important.
A Done Increment Doesn’t Mean Shipping a Pacemaker Every Sprint
The idea of creating an Increment every Sprint sometimes produces another objection when Scrum is discussed in hardware and medical device organizations: “We can’t release a medical device every two weeks.”
Of course not.
Scrum doesn’t require a medical device company to put a partially completed device into a patient’s hands at the end of every Sprint. A Done Increment and a commercially released medical device aren’t necessarily the same thing.
In hardware medical device development, the Increment might contain an integrated combination of hardware, software, firmware, electronics, mechanical components, documentation, test results, manufacturing information, or other elements necessary to create a useful step toward the Product Goal.
What matters is that the Increment meets the Definition of Done and gives us something real to inspect. We are trying to create integrated, usable progress rather than allowing partially completed work to accumulate throughout the organization for months.
Nobody needs to ship a pacemaker every Sprint. We do need to be honest about what we’ve actually finished.
Hardware Changes the Economics of Small Batches
Hardware development creates constraints that many software teams don’t have to think about as often. Physical components need to be fabricated. Suppliers have lead times. Laboratory equipment may have to be scheduled. PCBs cost money and take time to produce. Custom tooling can be extremely expensive. Manufacturing processes may need to be established and validated.
You can’t refactor an injection mold as easily as you can refactor a software class.
That doesn’t make small-batch development less valuable. In some cases, it makes it more valuable because a bad decision can become increasingly expensive to reverse as the product moves toward production.
The practical question becomes: how much can we learn before making the next expensive commitment?
Maybe we don’t need production tooling yet. Perhaps we can use a less expensive prototype to test the geometry first. Maybe we can simulate part of the system before fabricating it. We might test an interface with clinicians before committing to a physical control layout. We might integrate two critical subsystems earlier instead of allowing separate engineering groups to optimize their portions of the product independently for another six months.
Scrum in medical device development doesn’t make hardware behave like software, and pretending otherwise would be foolish. Instead, Scrum encourages us to look for opportunities to create meaningful feedback before committing larger amounts of money and time.
Sprints Don’t Eliminate Regulatory Milestones
Working incrementally doesn’t mean that every activity involved in medical device development can be broken into identical Sprint-sized pieces. Medical device organizations may still have formal milestones involving design reviews, design transfer, design freezes, verification and validation, regulatory submissions, and other checkpoints established by their quality system and applicable requirements.
Scrum doesn’t need to replace those milestones.
The work performed within Sprints can continuously move the product toward larger milestones while giving the organization opportunities to learn along the way. Instead of arriving at a major checkpoint with months of unintegrated work and unanswered questions, the team can arrive having already integrated important parts of the product, challenged assumptions, addressed risks, and learned considerably more about how the design actually behaves.
There may also be points where changing the product becomes deliberately more controlled and expensive. A design freeze, for example, exists for a reason. Formal verification may depend on a sufficiently stable design, controlled test methods, approved protocols, appropriate configuration management, and other controls required by the organization’s quality system.
Scrum doesn’t require an organization to pretend those constraints don’t exist.
The goal is not to eliminate gates. It’s to avoid waiting for the gates to discover things we reasonably could have learned earlier.
Sprints and regulatory milestones can therefore operate at different levels. Sprints give us frequent opportunities to inspect and adapt the developing product, while larger quality and regulatory milestones provide controls that may be necessary before the product moves into subsequent stages of development or commercialization.
Small Batches Can Reduce the Cost of Being Wrong
One of the reasons small batches are so powerful is that they change the economics of mistakes.
If an organization makes one hundred interconnected decisions before obtaining meaningful feedback, discovering that an early assumption was wrong can invalidate a large amount of downstream work. Requirements may need to change, designs may need to be revised, components may need to be rebuilt, documentation may need to be updated, and tests may need to be rewritten.
The cost isn’t simply fixing the original mistake. It’s dealing with everything that was built on top of it.
When we work in smaller batches, we create more opportunities to discover incorrect assumptions before they become deeply embedded in the product. That doesn’t guarantee we’ll discover every problem early. It doesn’t eliminate rework, and it certainly doesn’t eliminate risk. Complex product development doesn’t offer those guarantees.
It simply gives us more opportunities to learn while the cost of changing direction may still be manageable.
Safety Is Not Competing With Value
Organizations sometimes create an artificial separation between “business work” and “compliance work.” Product development creates customer value, while safety, quality, documentation, and regulatory activities are treated as costs imposed on the “real work.”
That’s a dangerous way to think about a medical device.
Safety is part of the product. Quality is part of the product. Regulatory compliance is necessary if the organization intends to legally bring the product to markets in which those regulations apply.
A capability that customers desperately want but exposes patients to unacceptable risk isn’t valuable. Likewise, a beautifully engineered product that can’t satisfy applicable regulatory requirements doesn’t have much commercial value to a company intending to sell it.
This is why Product Backlog ordering should reflect the real economics of the product rather than feature count alone. Sometimes the most valuable thing the team can work on will be a new capability that clinicians are asking for. Sometimes it will be mitigating an important safety risk. Sometimes it will be answering a difficult engineering question. Sometimes it will involve regulatory work. Sometimes the highest-value outcome will be discovering that an idea isn’t viable before the company invests another year and several million dollars pursuing it.
Value has more dimensions than features.
Learn Early Without Confusing Learning With Formal Verification
Small-batch development also challenges another assumption that can creep into product development: that we should wait until formal verification or validation to discover whether our ideas actually work.
That doesn’t mean testing something during a Sprint automatically satisfies formal verification requirements. There is an important distinction between testing performed to learn during development and formal verification or validation activities performed under the organization’s quality system.
During development, a team might build a prototype, test a sensor under realistic conditions, put an early interface in front of representative users, integrate two subsystems, or deliberately stress a design to expose weaknesses. Some of this work may be exploratory or formative. Its purpose is to help the team learn, challenge assumptions, uncover risks, and make better product decisions while changing the design is still relatively inexpensive.
Formal verification is a different matter. Depending on the product and applicable requirements, it may require an appropriately controlled design, approved protocols, defined acceptance criteria, controlled test environments, configuration management, documented results, and other procedures established by the organization’s quality management system. Formal validation introduces its own requirements and considerations.
Scrum doesn’t make any of that disappear, and a team shouldn’t casually treat exploratory testing as formal verification evidence when it doesn’t satisfy the applicable requirements.
But that raises an important question: why would we intentionally wait for formal verification to learn something we could have discovered earlier?
If a critical sensor is unreliable, I’d rather discover that with an early prototype than during formal verification. If clinicians consistently misunderstand an interface, I’d rather discover that through formative usability work while the design is still changing. If two subsystems behave unexpectedly when integrated, I’d rather learn that after a few months than after a design freeze.
Early testing and formal verification therefore serve different purposes, even though both contribute to developing a successful product. Early testing helps us learn while we still have options. Formal verification provides controlled evidence that specified requirements have been fulfilled.
Scrum gives us repeated opportunities to do the first without pretending that it eliminates the second.
The Sprint Review Becomes More Than a Demonstration
This also changes the purpose of the Sprint Review.
A Sprint Review shouldn’t merely be a meeting where developers demonstrate completed features while stakeholders politely watch. It is an opportunity to inspect the outcome of the Sprint along with stakeholders and determine what should happen next.
In medical device development, those stakeholders can represent different perspectives. Engineering may see a technical opportunity. Quality may identify something that deserves attention. Regulatory expertise may influence future decisions. Manufacturing may expose a constraint that wasn’t apparent to the development team. Clinicians or other users may react differently to the Increment than designers expected.
Those perspectives are useful while there is still time to act on them.
The point isn’t to ask everyone whether they “approve” of what the team built. The point is to expose the actual state of the product, discuss what has changed, and use that information to make better decisions about what happens next.
That is a much richer feedback loop than waiting for major checkpoints after months of development.
The Scrum Loop for Medical Device Development
When you strip away the terminology, the underlying approach is fairly straightforward.
We identify the problems worth solving and order them based on what we currently understand about value, safety, risk, uncertainty, dependencies, and other relevant considerations. The Scrum Team selects work toward a Sprint Goal and creates an Increment that meets its Definition of Done. We integrate what we’ve built, inspect the result, gather information, involve the appropriate stakeholders, and learn from what actually happened.
Then we reconsider what we thought we knew.
Maybe the Product Backlog order still makes sense. Maybe something we learned causes an item to become much more important. Perhaps a risk we were worried about is no longer as significant as we thought. Maybe a technical assumption turned out to be wrong and the product needs to change direction.
Then we repeat the process.
The Product Backlog helps us make decisions about what deserves attention. The Sprint creates a short feedback loop. The Increment gives us something real to inspect. The Definition of Done creates transparency around quality. The Sprint Review creates an opportunity to inspect the product with stakeholders and adapt what we do next.
None of those things eliminates the realities of regulated medical device development. They help us deal with those realities while we still have options.
Scrum and Compliance Are Not Opposites
There’s an assumption behind many objections to Scrum in regulated industries that deserves to be challenged. If a product needs to be controlled, documented, verified, validated, and compliant, people sometimes conclude that the development process itself therefore needs to be highly predictive.
Those are two different questions.
The first question is what standards, regulations, quality controls, and evidence our product and development process must satisfy. The second question is how we should manage complex product development when we can’t know everything in advance.
Regulations, standards, the organization’s quality management system, and other applicable requirements help answer the first question. Scrum can help us deal with the second.
Those ideas aren’t inherently incompatible. In fact, FDA currently recognizes AAMI TIR45:2023, which specifically provides guidance on using Agile practices in the development of medical device software. Note the scope: TIR45 addresses software development, while the QMSR governs the quality management system more broadly, so the two shouldn’t be conflated. That doesn’t mean every Agile practice is automatically appropriate for every medical device, nor does using Scrum establish regulatory compliance. It does demonstrate that Agile development and medical device regulation aren’t automatically opposing concepts.
The more interesting question isn’t whether we’re allowed to learn incrementally. It’s how quickly we can learn while maintaining the rigor the product requires.
Build Smaller Batches of Evidence, Not Just Smaller Batches of Features
This may be the most useful way to think about Scrum in medical device development.
The goal isn’t simply to build features faster. It’s to build smaller batches of evidence.
Instead of accumulating six months of assumptions before testing them, find opportunities to test important assumptions sooner. Instead of allowing separate components to evolve independently until a major integration event, integrate earlier when practical. Instead of postponing quality activities until the end, incorporate the appropriate quality expectations into what Done means. Instead of treating safety work as something competing with product development, recognize that developing a safe product is product development.
This is particularly important because progress in complex product development is easy to fake. A hundred completed engineering tasks can look impressive while the most important technical assumption remains untested. A beautiful project plan can show a product as 70 percent complete even though nobody knows whether two critical subsystems will work together. A feature can appear finished while substantial verification, documentation, or risk-management work remains outstanding.
Scrum asks us to be more honest about progress. What have we actually built? What is actually Done? What have we learned? Based on what we know today, what is the most important problem to solve next?
Scrum Isn’t About Moving Fast. It’s About Learning Before It’s Expensive.
Medical device companies shouldn’t use Scrum because they want an excuse to move fast and break things. That’s a terrible strategy when the thing you’re building may affect someone’s health or safety.
The stronger case for Scrum in medical device development is that complex product development contains uncertainty whether we acknowledge it or not.
We can make large batches of decisions, build large amounts of product around those decisions, and eventually discover whether our assumptions were correct. Or we can deliberately create shorter feedback loops.
We can attack important risks earlier. We can solve problems in smaller batches. We can integrate whenever it makes economic and technical sense. We can inspect real results instead of relying exclusively on predictions. We can incorporate applicable safety, quality, and compliance expectations into our Definition of Done so unfinished work doesn’t quietly accumulate behind us.
Scrum doesn’t eliminate controlled development. It helps us reduce uncertainty before control becomes expensive.
Small batches don’t mean less rigor. They mean reducing the amount of product, money, time, and confidence we pile on top of an assumption before finding out whether that assumption was right.
For medical device development, that’s not an argument for being reckless.
It’s an argument for learning sooner.
Frequently Asked Questions About Scrum in Medical Device Development
Can Scrum be used for medical device development?
Yes. Scrum can be used to manage complex medical device product development, but Scrum doesn’t replace the organization’s quality management system or applicable regulatory requirements. The value of Scrum is in creating shorter feedback loops and helping teams inspect and adapt the developing product while maintaining the necessary rigor.
Can Agile be used for FDA-regulated medical devices?
Agile practices can be used in medical device development while complying with applicable FDA requirements. FDA recognizes AAMI TIR45:2023, which specifically addresses the use of Agile practices in medical device software development. Recognition of the standard should not be interpreted to mean that using Scrum or another Agile approach automatically establishes regulatory compliance.
How does the Definition of Done work in medical device development?
The Definition of Done establishes the quality measures required for an Increment. In medical device development, applicable safety, quality, documentation, testing, traceability, and compliance expectations can contribute to what the organization requires before work is considered Done.
Does Scrum replace medical device verification and validation?
No. Testing performed during a Sprint doesn’t automatically constitute formal verification or validation. Teams can use exploratory and formative testing throughout development to learn and reduce uncertainty while still performing formal verification and validation activities under the appropriate controls when required.
Does Scrum eliminate design freezes or regulatory stage gates?
No. Medical device organizations may still require design reviews, design freezes, formal verification and validation, design transfer, regulatory submissions, and other controlled milestones. Sprints can help teams reach those milestones with more integrated work, fewer unresolved assumptions, and better information.
How can Scrum work with hardware development?
Hardware introduces constraints such as fabrication time, tooling costs, component lead times, suppliers, laboratory testing, and expensive physical changes. Scrum doesn’t make those constraints disappear. Instead, teams can look for economically sensible ways to test risky assumptions, prototype, integrate, and learn before committing to expensive or difficult-to-reverse decisions.
