Doing Agile in a GXP or medical devices environment requires you to serve two masters: you need to practice the Agile disciplines on one side, and embrace regulatory requirements on the other.
In order to strike the balance, you must understand the difference between “stories” (Agile term) and “specifications” (Design Controls term). From my experience working with many teams that are “Agile first,” I have seen firsthand how easy it is for people to believe that Agile stories are the same as specifications.
Not only are they not the same, but also the difference is critical to how you work and your “Definition of Done.”
A story describes a new requirement or a modification to an existing one. There is a certain language formula to a story, including emphasising business value and all the other Agile-esque nuances. The key is that it does not necessarily describe the product, but rather the incremental change that is required.
In Software Development Life Cycle (SDLC) terms, a specification (i.e. a user requirement) expresses a regulatory requirement that the product (or the system) needs to meet in a subsequent version.
For example:
An Electrocardiogram (ECG) device provides an innovative report that features a special analysis of the ECG signs.
- Version 1.0 is developed:
- Development gets a story: “Doctor needs a report so that [details of the report are provided].”
- User requirement: “Doctor needs a report with the following specs: [details of the reports are part of that specification].” (In this case, you could use the exact same language as the story.)
- Enter Version 2.0 development:
- Development gets a story: “Doctor needs the report to also include a calculation of X in a separate column.”
- User requirement: “Doctor needs a report with the following specs,” and details of the report are part of the specifications. These details (of that extra column) are now updated to also include the new data mentioned in the story of version 2.0.
As the product evolves, stories describe the small changes that are introduced throughout the development cycle. A specification of the product in a given release version provides the description of the feature at the particular time of release. This is not to say that a story cannot also be a specification – it can be, but it certainly is not always the case. As a product matures, and each version is an increment, a story becomes less likely to be a specification.
Updated versions of a product may include the following types of specifications:
- Those that remain the same as they were in the previous version.
- Those that change from previous version.
- Entirely new specification elements, which are added if new features are implemented.
Once you understand this difference, you can still work Agile. However, now your “Definition of Done” will account for this. A story is done only when specifications have been updated to reflect how the product is after implementing the story.
While you could leave specification updates to anytime before the release, making it part of your story work (“Definition of Done”) is advantageous because it gives you a more realistic idea of your progress. If you don’t update specifications on an ongoing basis, then you risk unexpectedly delaying the release because you have to add them at the end. Specifications also become a helpful, more detailed reference for developers and testers during the release that more closely reflect the development version they’re using.
When designing in a regulated environment, it’s crucial, then, that you get your story straight – and differentiated from your specifications. Not only will it clarify your mission, but it also ensures a happy ending for your version.
