Risks and Issues

How to Create and Use a Risk Issue Type

The recommended way to track risks at the team (Level 3) is to create a dedicated Custom Issue Type called "Risk" or "Project Risk" within your Space configuration.

1. Create the Custom Issue Type: As a Jira Administrator or Space Administrator (depending on if it's a Company-managed or Team-managed space), you would navigate to the Issue Types section in your project settings and create a new Standard issue type. You would name it Risk and give it a unique icon.

2. Define Custom Fields (The Risk Model): For a Risk issue to be useful, it must capture specific risk-related data.You should create custom fields to define your risk model. The two most important fields are:

   • Likelihood: A select list (e.g., Low, Medium, High, Almost Certain).

   • Impact: A select list (e.g., Low, Medium, High, Critical).

   • You might also add a custom field for the Mitigation Plan (a multi-line text field) and a field for the Risk Owner.

3. Configure the Workflow: A risk doesn't follow the same workflow as a story. You should create a custom workflow for the Risk issue type with statuses like:

   • New → Analyzing → Mitigating → Monitored → Resolved/Accepted.

4. Link to Execution Work: Once a Risk is identified, it must be linked to the work it affects. For example, a Risk issue titled "Dependency on external API is not yet confirmed" should be linked to the Story (Level 3) or Epic(Level 2) that relies on that API. This ensures team members are immediately aware of the potential threat when they look at the work card.

Purpose of Tracking Risks at Level 3

Tracking risks at the execution level serves a distinct and vital purpose compared to tracking them at the portfolio level: proactive management and immediate mitigation.

• Execution Focus (Risk vs. Issue): At the team level, a risk is a potential problem that could impact the current or next sprint. By creating a Level 3 Risk issue, you force the team to treat the identification and mitigation of that risk as a concrete piece of work. This is then often handled using the ROAM technique (Resolved, Owned, Accepted, Mitigated) which can be built into your custom risk workflow.

• Traceability to Tasks: When a team decides to mitigate a risk (e.g., "The risk of running out of server space is High"), they typically create one or more standard Tasks (Level 3) that represent the actual work to reduce the risk (e.g., "Implement server health monitoring"). By linking the Risk issue to these Mitigation Tasks, you can track the progress of the preventative work directly on the team's board, ensuring the risk is actively managed and does not turn into an actual Bug or Blocker.

This approach embeds risk management directly into the daily activities of the delivery team, allowing them to own and resolve threats without external escalation until absolutely necessary.

Reporting Level 3 Risks Up the Hierarchy

The integration of execution-level risks into strategic planning is handled primarily through linking and visualisation tools in Jira, particularly within Advanced Roadmaps.

The Power of Linking: From Risk to Initiative

The core mechanism for reporting is the Issue Link. When a team identifies a Level 3 Risk (e.g., "High chance of a legal compliance delay"), that Risk issue is linked to the affected Epic (Level 2), which is in turn linked to the strategic Initiative (Level 1).

• Risk to Epic/Story: The team links the Risk issue to the relevant execution cards (Stories/Epics) using the Blocksor Relates To link type.

• Roll-up: Because the Epic is already part of the long-term plan in Advanced Roadmaps, when a team marks a risk as "Critical" or "Blocked," the status of that risk is inherently factored into the Epic's overall health and estimated completion time.

Visualisation in Advanced Roadmaps (Plans)

Advanced Roadmaps provides the tools necessary to surface these granular risks to the portfolio level:

• Dependency Visualisation: If the Risk issue represents a dependency (e.g., waiting for an external vendor), the program manager can use the Plan's dependency reports to see how the status of that dependency/risk is impacting the entire Initiative's timeline. A high-risk dependency might cause the Plan to automatically flag a projected date conflict for the Epic.

• Custom Field Reporting: If the team uses custom fields like "Likelihood" and "Impact" on their Level 3 Risk issue, these fields can be surfaced and aggregated in custom reports or views within Advanced Roadmaps. This allows portfolio managers to see a macro-level risk matrix for their entire program, showing the total number of High-Impact risks currently affecting their various strategic Initiatives.

• Informed Decision Making: By seeing the execution-level risks in their strategic Plan, executives can make informed decisions about resource allocation. For instance, if a major Initiative is blocked by three high-impact Risks, leadership may decide to pull developers off other work to focus entirely on mitigating those threats, protecting the strategic goal.

In summary, the Level 3 Risk issue acts as the flag that alerts the system, and the linking hierarchy acts as the escalation path, ensuring that a team's execution challenge immediately translates into a visible threat on the organization's strategic roadmap.