Using Jira for requirements management? Extending this to managing medical device risks is the logical next step. There is a complete article about how to configure the risk issue type in Jira. Here I will focus on the workflow for risk issue type.
The workflow for risk issues is not isolated. Risk issues are part of the tapestry of product design activities and related records.
This gist is this:
The product specifications are the input to the risk identification process.
Functional specifications are the main method to mitigate risks. The functional specifications also drive development stories. When developers move the stories to DONE they construct the product release. Functional specifications, in turn, transition to RELEASED when we release the product.
A mitigated risk is set into CONTROLLED status.
In short, three issue types are at play: risks, functional specifications, and stories. (In fact, there are also user requirements but they are more in the background. We leave them out for sake of simplicity).
While all three are equal citizens in Jira (all are issue types), they serve different needs and need a different type of workflow.
- A development story drives development work that results in code modifications. When a story moves to DONE our software product has a new behavior or feature that it did not have before. The story is now of limited value and does no longer serve us. A well formed story is one that drives good changes in the code.
- Functional specifications describe the product and serve as the benchmark for product tests. When the functional specification is first agreed upon it drives development stories to make it part of the product. The functional specification remains applicable as long as it describes the product. Often this spans many years.
- Risk issues are evidence of the systematic risk analysis process. We add them in Jira so that they constrain functional specifications. When a functional specification has a risk-mitigating role, any change requires more diligence.
A fuss-free workflow for risk issues
Risk issues step through a simple workflow:
StatusMeaning
| DRAFT | When the idea of a potential risk is still not analyzed and understood, it is in DRAFT. For now it is a quick idea about a potential product risk. |
| RISK ASSESSMENT | In this status, we analyze the risk and documented it in the most accurate way. Product manager and the risk assessment team will often do this during a brain storm, collaborative, session. |
| RISK CONTROL | Now, the product team works to identify ways to mitigate the risk. The mitigations can be of three types:
When the risk issue is in the status, we link it to the mitigating functional specification. These links serve as the constraint to the functional specification issue. |
| CONTROLLED | In this status, the risk serves as a controlling element. An active reminder to not change functional specifications without re-assessment of the risk. |
| CANCELLED | Risk may be cancelled shortly after creation. We analyzed it and decided it was non-sense. Changes in the product may also trigger the cancellation of a risk. Removal of features, for example, can remove some risks. |
The workflow supports the iterative process of ongoing product updates. Do you need to reconsider the risk controls of a risk that is already in controlled state? Revert it from the CONTROL status to the RISK CONTROL status.
You can use this strategy to ensure that do not forget to re-evaluate risks. Do not issue a new risk analysis report if any of the risks are still in RISK CONTROL status.
Constraining changes to risks
A nice feature of Jira workflows is that you can limit the edits of issues in certain workflow statuses. For the risk workflow, It’s reasonable to limit edits when the risk is in CONTROLLED or CANCELLED status.
This implementation detail is sometimes obscure. Here is a quick explanation of how to achieve this. In the Jira workflow designer, edit the workflow and add these properties (or a variation of them) to the status you want to constraint:
Property nameProperty valueMeaning
| jira.permission.edit.group | jira-admins | Only people in the Jira group ‘jira-admin’ can edit the issue |
| jira.permission.attachdeleteown.group | jira-admin | Only people in the Jira group ‘jira-admin’ can delete their own attachments |
| jira.permission.attachdeleteall.group | jira-admins | Only people in the Jira group ‘jira-admin’ can delete any attachments |
These limitations are beyond the permissions granted via the permission scheme. For example, if a user does not have edit permission via the permission scheme, then these properties will not be enough to enable this.
Read more about workflow properties.
From risk issues to risk analysis report
Once you are ready to release, you’ll need to have a risk analysis report. The report lists all your CONTROLLED risk issues that are applicable to this version.
If you are using Confluence, check out the Jira Snapshots app. It is the easiest way to create this document in Confluence. Jira Snapshots brings static copies of Jira data into Confluence. A vital ingredient for official documentation.
Jira Snapshots also supports traceability reports and removes delays caused by manual traceability. Read all the details about easy release documentation.
Fluent risk management
Although this is not obvious, risk management can find its perfect home in Jira. Configuring risk issues with a simple workflow and the correct set of fields is all you need to weave risks into the Jira tapestry.
A connection with Confluence and with Jira Snapshots is taking this to the next level. Enabling fluency not only in the risk analysis process but in the release as a whole.
