If your team is working on a Software as a Medical Device (SaMD), you’ll probably choose an Agile approach. Running sprints, computing velocity, grooming, retrospectives — all of that lingo becomes part of your culture.
But just because the word “agile” means quick and makes iteration sound like a snap, regulatory requirements can grind the process to a halt. And what often stands in the way is release documentation.
Here’s how it typically plays out:
The new software is implemented and tested, ready for release in the internal teams’ eyes. All that’s left is the documentation, and how long can that take?
The answer might make you sorry you asked. Days go by, then weeks. The challenge then becomes remembering all the details. Product managers and testers scratch their heads, and developers dig into their code. Who can remember exactly if this test case fully covers that requirement, and did we implement it exactly as described?
Soon it’s clear that release documentation can be the sticking point for not only the development team but also for the morale of the company overall.
Avoiding that stickiness to keep things fluid and move forward smoothly all the way to release requires more than just an Agile approach.
How the Jira and Confluence integration can help
SaMD providers need to plan their Agile process and tools better. They need an Agile++ approach.
The Agile++ process is comprised of three elements:
- Appropriate tooling to manage all your traceable items: You have tools to manage stories, bugs, and tests. Make sure to extend your tooling to include ALL the traceable items, including requirements and risks. If you do not manage your stories and bugs in Excel, why would you settle with Excel for your requirements and risks?
- Extend the Definition of Done (DoD) for Stories: Make sure you also include an update of traceable items.
- Keep your eyes on the release documentation prize: Utilize decent tooling, so generating and reviewing critical documentation is a breeze.
By harnessing the power of Jira and Confluence together using Jira Snapshots for Confluence, you can ace these three elements. Here’s how:
How to manage your traceable items in Jira
If you’re an efficient SaMD creator, you use Jira for managing stories, bugs, and tests. If you’re not doing so already, it’s also well worth using Jira to also manage requirements and risks. (Be sure to check out our articles on Requirements Management and Risk Management for more details.)
That said, it’s understandable if you resist managing requirements in an issue separate from the story. It’s another issue type to deal with and may not appear necessary at first glance. However, this is a core issue that directly relates to why release processes often are delayed.
By separating the requirement from a story, you enjoy a more efficient structure for the work at hand by using a “divide and conquer” approach.
The case for separating issue types
The life cycle of a story is fundamentally different from that of a requirement.
- A story is created in the backlog, then implemented and tested.
When it reaches the “done” state, it typically means that it is part of a release. At this point, you do not expect it to change, and you stop “caring” about it. The story issue that helped you manage the implementation work is now gone.
Also, developers work on stories, and most aren’t of interest to anyone outside of the development team. - A requirement is a specification element and a documentation item.
A requirement is created to express a product specification. As such, it may not yet be part of the product. Once the product is released with the new specification, the status of the requirement, therefore, is not “done” but rather, “in product.” Typically, the requirement will remain “in product” for many versions, and sometime in the future may become obsolete (when another requirement replaces it).
Because requirements are an input (or output) of development work, they’re of interest to several parties, from product owners to stakeholders inside and outside the development team. For many of the same reasons, tests are also separate issues from stories. So, just like it’s common practice to separate tests from stories, it’s also advisable to separate requirements from stories.
Use a DoD that fits your SaMD’s needs
Similarly, just as developing a suitable test case is part of the DoD of a story, so is the requirement work.
Here’s how the process works:
- A new requirement or an update of an existing requirement is specified, approved, and triggers a story to implement the change;
- Once the development of the story is done, go back to the requirement and see if it needs further changes. This is the feedback loop between the implementation and official documentation and is done in concert with testing. Only after confirming that the specification correctly reflects the upcoming release can the story be declared as “done.”
Proceeding like this means that the specification work is progressing hand-in-hand with implementation work. This ensures there’s no accumulation of documentation debt.
As soon as the last story of the release is closed, the specifications are also ready.
There is a trade-off in this scenario. Each story will take a bit more effort, and your velocity might take a hit. But the net result is that you’re working consistently toward the ultimate business goal — the actual release of the SaMD (vs. merely finishing the software implementation).
Proper tooling to quickly generate and review release documentation
Once you have your specifications up to date and tests complete, all that’s left is finalizing the release documents.
Enter Jira Snapshots for Confluence. With a few clicks, you can create audit-ready release documentation that pulls all the right data and presents it in a user-friendly format.
Each document is laid out with the correct background/soft information (overview, version description, etc.). And most of the background can be written months in advance, so the Snapshots are already preconfigured to pull the correct data. This means that getting the documents ready for review is just a matter of minutes.
Best of all, Jira Snapshots for Confluence makes it quick and simple for stakeholders to review these critical documents. Because they can easily compare current data with the previous version of the specification, it’s clear that the release documentation is complete — and “done” is really done!
Picture-perfect release documentation
You have a job to do, and that’s to make the world a healthier, happier place with a SaMD that improves people’s lives. And, of course, regulators have their job to do, too — to make sure that you’ve done everything necessary to release compliant, safe Software as a Medical Device (SaMD) products into the marketplace.
It’s easy to see where this can get complicated, which is why a seamless Jira and Confluence integration is essential for any SaMD release. It empowers your Agile process to be really, truly agile by allowing you to separate issue types and serve your various teams and stakeholders’ needs simultaneously.
With so many other things to keep you up at night, the final step in the process — the release documentation — should be the least of your worries. That’s why we created Jira Snapshots for Confluence and also why we’re always happy to help if you have questions. Don’t hesitate to contact us.
