While agile and Scrum have many ceremonies, artifacts, and tools, a risk registry is not a standard one. Why is that?

Keeping teams in focus addresses many of the risks in releasing innovations that plagued IT teams in the pre-agile world and using waterfall project management. Scrum is really good at helping teams focus on a small window of priorities (the backlog) delivered in a short timeframe (a sprint). Agile is now a de facto standard and used in software development, low-code / SaaS, AI, data science, marketing, IT ops, and many other initiatives where changing requirements, technological implementation challenges, and fast customer feedback are the norm.

Scrum focuses on the happy path

Scrum mitigates short-term risks through its team structure, ceremonies, practices, and tools. Here’s a summary of how Scrum helps teams stay in focus sprint to sprint.

• Defined responsibilities for team leadership roles, including product owners, team leads, business analysts, and scrum masters.
• Ceremonies for commitment, standups, and retrospectives to ensure teams are aligned on priorities, discuss blocks, and drive continuous improvement.
• Stakeholders provide feedback at sprint planning and reviews, so they are grounded in the real-time realities of what teams are working on.  
• Agile teams use tools like Jira and Azure DevOps to manage backlogs, including features and user stories that are aligned to releases.
• Teams use agile estimation, continuous planning, and change management practices as part of their agile transformational practices.
• Reports like sprint and release burndowns help teams track whether their releases are on scope.

 Teams following Scrum and collaborating efficiently find ways to meet their sprint commitments and improve team velocity.

Meeting team sprint commitments isn’t good enough

Meeting sprint commitments, gaining stakeholder satisfaction at sprint reviews, and improving velocity are table stakes. What Scrum doesn’t fully address is whether

• Releases are on scope and deployed reliably +
• Customers and end-users received training, are adopting the new capabilities, are satisfied with the improved experiences, and ideally ecstatic with the impacts +
• Days after the deployment, is the product performing reliably, securely, and scaling as required +
•  Are the targeted business outcomes achieved +
• Is the feedback and data collected being used to drive the next set of priorities +
• Has new technical debt been identified, backlogged, and prioritized +
• Are other technical, security, operational, and data concerns being addressed +

All of these questions amount to risks, unknowns, and concerns. The challenge is whether agile teams are discussing and formalizing plans around them. Is there a venue for architects, security, data governance, and other experts to raise risks and concerns? Are risks ranked, remediations debated, and solutions prioritized?

Scrum doesn’t have a formal ceremony for discussing release, operational, or technology risks. The most commonly used agile tools, including Jira and Azure DevOps, don’t have out-of-the-box risk registries.

What I have found across most StarCIO clients is that they don’t have a process to manage agile delivery risks, or select teams are cataloging risks in spreadsheets.

What is an agile risk registry?

An agile risk registry is an artifact from a conversation around a team’s risks, issues, and concerns. The scope of risks includes meeting business objectives, adherence to technology standards, implementation uncertainties, and concerns about quality, safety, security, or other operational impacts.

Agile teams following StarCIO’s release management guidelines typically hold three release-level meetings for major releases. Discussing risks should be on the agenda at each of these meetings, and updating the risk registry is a key deliverable.

A risk registry typically captures

• The date when the risk was captured
• A title, description, and one or more categories around the risk
• An owner is assigned clearly defined responsibilities
• A ranking score, which can be captured as a probability of occurrence (1-10, 10 being the highest) and a business impact score (1-10, 10 being the highest). The ranking is calculated by multiplying probability by business impact, yielding a score that can be used to prioritize remediation.
• A high-level remediation plan, or a link to a document or wiki page with a more detailed plan.
• A status field, which can be a simple transition from Identified à Remediation in progress à Risk addressed.

Agile risk registry implementation options

Now, there are many options for creating a risk registry. I’m opposed to using spreadsheets because they don’t provide lineage and identify when risks change. They may be easy for agile teams to use, but pose greater challenges for product managers, delivery leaders, and Digital Trailblazers to monitor across all or groups of teams. If you are going to use a spreadsheet, then see this risk registry template, which you can download.

But there are better options.

• Atlassian has a Confluence template that is better than a spreadsheet, but still hard to use for larger organizations that want to manage risks both bottom-up (by team) and top-down (for multiple teams, including product families and platforms). Another option is Risk Register, a Jira marketplace tool, which I have not reviewed.
• Azure DevOps identifies risk tracking fields that can be included in work item types. Another option is this risk management extension.
• ServiceNow has a risk registry as part of its Governance, Risk, Compliance (GRC) solution.

StarCIO’s simple approach to developing an agile risk registry

Existing solutions might work for your organization, but I offer an alternative that’s easy to implement. My approach

• Focuses on the remediation and not just the risk.
• Makes it easy for teams to record risks and assign context.
• Simplifies tracking of how well agile teams working in product families, platforms, or across the organization record and remediate risks.
• Requires add-on components and capabilities that admins will likely already have in place and probably need for other workflow needs.

My approach requires a basic understanding of StarCIO’s Agile Planning Guides. In the guides, we separate two kinds of work item types:

• Epics and Features are containers for delivering capabilities, but the work isn’t performed under these two work types.
• User Stories are where the work gets done. In StarCIO Agile, we introduce several other custom work types.

StarCIO’s implementation of a risk registry

Below is StarCIO’s recommended implementation of an agile risk registry.

• Risks are a custom work item type. They are similar to Epics and Features in that they capture a goal (addressing a risk) and not the work to address it.
• Define custom fields for capturing risk, including:
  • Probability of occurrence (numeric)
  • Business impact (numeric)
  • Remediation plan (URL)
  • Ranking Score (numeric)
• The Ranking Score should be a calculated field, which has several implementation options:
  • Jira doesn’t support calculated fields natively, but the calculation can be performed with Jira Automations, JMCF, or ScriptRunner.
  • Azure DevOps also doesn’t support calculated fields, but Power Automate can be used to accomplish this task.
  • Zapier can also perform this automation on Jira or Azure DevOps.
• Admins can elect to use an out-of-the-box workflow to manage status like To Do à In Progress à Done, or customize the status levels I suggested, Identified à Remediation in progress à Risk addressed.
• Risks are formally added and discussed during release meetings, but as a work item type, they can be added by anyone at any time.  
• As Risk is now a work type, it can be used to link user stories and other work items used to perform remediation work.  
• Risk is also easy to report on;
  • It’s on the backlog, so agile teams can’t ignore it.
  • A full risk registry across teams can be built using Jira’s JQL or Azure DevOps Queries.
  • More dynamic dashboards can be created by connecting Tableau or Power BI.

Use extendable components for configurations

You can argue that the work to create the Ranking Score no longer makes this a “simple approach.” But the tools I’ve recommended are all commonly used for other tasks in Jira / Azure DevOps. It’s reasonable to assume that admins on these tools have automation or dynamic field solutions they already use.

Feel free to reach out if you want to learn more about StarCIO’s release management guidelines.