This is a basic workflow I’ve used with teams to capture risks and issues. I’ve used a issue type ‘Risk’ for things that might happen and ‘Issue’ which has already happened and that needs to be resolved.
Suggested Fields (non-exhaustive)
Risk title
Description: what is current assessment and what is the risk
Mitigation
Impact (scale 1 -5)
Likelihood (scale 1 – 5)
Colour (Red / amber / green)
Component
Owner
Estimate (days required to fix should the risk happen)
Epic link
Jira Columns on a kanban board were very simply:
Open | Acknowledged | Owned | Resolved
The statues map to the columns, with all five resolved statuses sitting within the Resolve column. I had risks and issues in the same board.
I used filters to indicate if the risk or issue needs to be escalated. This was particularly important in any scaled ceremonies such as ‘Scrum of scrums’ (SoS or SoSoS), where we could review only escalated risks or issues.
Dashboards were also very effective at highlighting priority risk, and metrics such as where they sit (epic or component) as well as time unresolved.
One further option is to track the risk burn down by estimating how long in man days it would take to rectify a risk, should the risk materialise. Added together, this number can give you an indication of exposure which leadership teams can use to in discussions.
A principle may be to escalate an issue to the next level up if it cannot be resolved within a sprint. In practice I found this difficult to achieve (since our agile maturity still needed some way to go before this was feasible).