Regardless of which Agile methodology you follow, there are two concepts you should learn to value: the definition of ‘ready’ and the definition of ‘done’.
In this article, we’ll look closer at:
The definition of ‘ready’ acts as a gatekeeper; it helps teams decide if a task has been prepared enough to start. For instance, are you ready to read this article? Clearly, yes, since you are already reading it.
The definition of ‘done’, on the other hand, ensures that once work begins, everyone agrees on what it means for that work to be truly complete.
The definition of ‘done’ determines when a task is finished, such as reading this article all the way to the end. AAMI TIR45 defines ‘done’ as follows:
term usually referring to completion of all activities necessary to deliver usable software, with varying degrees of “DONE” applying to the PRODUCT, RELEASE, INCREMENT, and STORY LAYERS; the concept of “DONE” is critical in AGILE approaches; because of the emphasis on delivering usable software and achieving results over activity, defining what “DONE” means is central to defining an AGILE life cycle model, associated processes, and product/project success criteria; variations and phrases include “Definition of DONE,” “DONE DONE,” “DONE is DONE and “DONEness” (as in degree of achieving “DONE”)
The definition is lengthy and carries several perspectives. Firstly, ‘done’ is a “term usually referring to completion of all activities necessary to deliver usable software”. This is straightforward, but then the definition continues to say, “with varying degrees of “DONE” applying to the PRODUCT, RELEASE, INCREMENT, and STORY LAYERS”.
This might come across as confusing since the word done is considered a binary state by most people. Either something is done, or it is not.
However, the definition brings forth an essential point because when working on a story in Agile development practices, ‘done’ can mean different things. For instance, requiring a full system test to be performed each time a story is implemented is probably not meaningful; it is more efficient to run system tests on a batch of implemented stories. Or, when working on documentation, there is no need for unit testing. So, clearly, different types and various degrees of ‘done’ need to be considered, and the same logic applies to ‘ready.’
When applying definitions of ‘ready’ and ‘done’ to Scrum, the ‘ready’ state helps determine what goes into the next sprint. In a medical device context, a definition of ‘ready’-checklist might include items such as:
Having these conditions in place helps ensure that sprint work supports both development needs and regulatory expectations.
Meanwhile, the definition of done acts as a checkpoint to determine whether tasks have been completed. This could, for example, include checking for updated design documentation and test coverage.
If requirements are allowed to be adjusted during a sprint, re-reviewing changed software requirements would probably be appropriate to ensure that the updated requirements do not conflict with already implemented requirements.
Following the definition in AAMI TIR45, ‘done’ can be used for different purposes at different layers. Layers is a concept introduced by AAMI TIR45 and is used to explain that various activities can be conducted at different stages in your Agile development practices.
Both the definitions of ‘ready’ and ‘done’ can be used to conform to IEC 62304 requirements, such as verifying software requirements and architecture.
Clear definitions also support ISO 13485 by making design and development activities traceable and repeatable. When auditors or regulators review your process, being able to point to a documented definition of ‘ready’ and ‘done’ shows that the team has a consistent method for deciding when work can begin and when it is complete.
This reduces the risk of audit nonconformities, improves the quality of the design and development file, and makes it easier to demonstrate compliance.
In a more generic context, checklists can be implemented to verify requirements characteristics. Requirements shall be necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct, and conforming.
| Characteristics for individual requirements | Characteristics for sets of requirements |
|---|---|
|
Necessary
|
Complete
|
|
Appropriate
|
Consistent
|
|
Unambiguous
|
Feasible
|
|
Complete
|
Comprehensible
|
|
Singular
|
Able to be validated
|
|
Feasible
|
|
|
Verifiable
|
|
|
Correct
|
|
|
Conforming
|
|
There are also characteristics for sets of requirements. Even if one requirement is worded perfectly, other requirements might be overlapping or contradicting, which is why characteristics for sets of requirements also need to be considered. These characteristics state that sets of requirements shall be complete, consistent, feasible, comprehensible, and able to validated.
To learn more about writing requirements for medical devices, see Peter Sebelius’ online course on medical device requirements engineering.
By tailoring the definitions of ‘ready’ and ‘done’ to an organisation’s needs, they can support design and development review activities as defined by the quality management standard ISO 13485.
7.3.5 Design and development review in the ISO 13485 standard states that systematic reviews of design and development shall be performed at suitable stages in order to:
a) evaluate the ability of the results of design and development to meet requirements;
b) identify and propose necessary actions
When, for example, verifying if a software architecture implements software requirements, the architecture’s ability is evaluated to determine if it meets the requirements. And Agile is all about identifying and proposing necessary actions since Agile methodologies embrace feedback and changes.
However, a word of caution! Replacing formal design reviews with just working with Agile will not suffice in the medical device industry. Please ensure that you can identify at which layers your definition of done and definition of ready act as a formal design review, and that you can easily identify the results of those activities.
The extent to which formal design reviews can become integral to Agile development practices depends on the scope of your process. For SaMD products, there is a good chance that design reviews can be fully included in Agile activities. But in mixed environments, design reviews will likely occur outside of an Agile software development process because the design reviews should look at the entire product, not only parts of it.
It is up to you to explore what makes sense in your organisation. However, a recommendation is to use a combination of increment and release layers, as conducting design reviews at the story level is probably too early and too often, while waiting until the product layer would be too late.
In summary, the definitions of ’ready’ and ‘done’ can become invaluable when designing a medical device software development procedure. The concepts are known to developers, and by adding a few teaspoons of extra work to the activities, you almost get conformance to relevant standards for free.
Looking ahead, organisations that consistently apply clear definitions of ‘ready’ and ‘done’ not only streamline Agile development practices and teamwork but also build a stronger foundation for regulatory compliance and faster adaptation to future changes in standards and technology.
Now, you are formally done with reading this article.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
Already familiar with the standards and interested in Agile? See our Agile medical device software development course.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC62304 and also actively participated in the creation of IEC82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
Special launch offer: 349 299 EUR for the online plan & 449 349 EUR for the online lifetime plan.
