Effective Risk Management with Scrum in 6 Easy Steps

One of the most important responsibilities of the ScrumMaster is to remove impediments or obstacles impacting the Scrum team. If they are already affecting the Scrum team’s productivity, they can be classified as issues. The sprint retrospective is a formal ceremony or meeting where the team inspects how they did during the last sprint, including how well they managed risks and issues, and where they identify and implement an action plan to address any opportunities for improvement. The Scrum team doesn’t need to wait until the sprint retrospective in order to make improvements, including quality and performance.

Every project manager, let alone organization, implements risk management differently. While there are many variations of how and why to perform risk management, let’s break it down to the basics.

Risk Vs. Issue

A risk indicates a particular aspect of a development task, process, or environment, which, if ignored, will increase the probability of project failure (Lyytinen, Mathiassen and Ropponen 1998). In essence, there are two ways to define risk, one is in quantitative and the other one is in qualitative.

The key in performing effective risk management is being proactive as opposed to being reactionary. Proactive risk management is identifying and managing risks before they become issues. Reactionary risk management is essentially issue management, because it involves reacting to an issue which has already started impacting a project. “Firedrills” are primary examples of these types of issues, where they are emergencies and require all hands on deck.

Why Risk Management?

75% of business and IT executives anticipate their software projects will fail. (Source: Geneca – http://www.geneca.com/75-business-executives-anticipate-software-projects-fail/). Fewer than a third of all projects were successfully completed on time and on budget over the past year. (Source: Standish Group – http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf). In 2013, a survey from cloud portfolio management provider Innotas revealed that 50 percent of businesses surveyed had experienced an IT project failure within the previous 12 months. Now, three years later, not much has changed. According to the most recent Innotas annual Project and Portfolio Management Survey, in fact, the numbers have increased: 55 percent of the 126 IT professionals surveyed between January and March 2015 reported they had a project fail, up from 32 percent in 2014. https://www.cio.com/article/3068502/project-management/more-than-half-of-it-projects-still-failing.html

Tushar Patel, senior vice president of marketing, Innotas: “most people get in the car and start driving and they just trust that the resources, the map and the direction are already taken care of. You have to address those issues before you even set out on the road — that’s the same thing we’re seeing, here.”

So what do we need in order to perform risk management? According to Barry W. Boehm in his paper “Software Risk Management: Principles and Practices” (1991), he identifies two primary categories for software risk management: risk assessment and risk control.  Each category contains 3 steps.

Risk Assessment
1. Risk identification: produce lists of the project-specific risk items related to a project’s success
2. Risk analysis: assess the loss probability and loss magnitude for each identified risk items and it also analyzes compound risks in risk-item interactions.
3. Risk prioritization: produce a ranked ordering of risk items identified and analyzed.

Risk Control
4. Risk management planning: help prepare you to address each risk item (e.g. via information buying, risk avoidance, risk transfer, or risk reduction), including coordinating individual risk-item plans with each other and with the overall project plan.
5. Risk resolution: generate a situation in which the risk items are eliminated or resolved.
6. Risk monitoring: track the project’s progress in order to resolve its risk items and take corrective action where appropriate.

So what do we use to document and manage risks? I recommend starting off with a Microsoft Excel spreadsheet. I’ve seen it referred to as a “risk register”, “RAID Log”, “IRAD”, etc. Essentially, your spreadsheet would have four tabs – one for risks, one for action items (or assumptions), one for issues (or impediments), and one for decisions.  (There are tools that will manage this information as well, but let’s start simple for now.)

Information to capture on the “risks” tab should include:
• Risk Description
• Identified By
• Date Identified
• Level of Risk Impact (1 – Minimal to 5 – Severe)
• Category of Risk Impact (e.g. what part of the project will be impacted by the risk? Cost? Scope? Resources? Schedule? Infrastructure?)
• Mitigation Plan – this information is essential, because this specifies how you plan on mitigating the risk and preventing it from becoming an issue, and having a definitive impact on your project.  This plan should be updated as more information about the risk becomes available (much like a user story is updated in the Product Backlog during Product Backlog grooming as more information becomes available).
• Assigned To – Who is actively working on mitigating this risk?
• Status – I recommend adding a line for each status update.  I preface each line with the date of the status update.  As an example:

12/5/2017 – Brian Green from ABC Vendor contacted me regarding status of patch release.  Was told that the patch will be released January 2, 2018.  This patch will solve this technical issue which is putting the release of this user story at risk.

12/2/2017 – Reached out to ABC Vendor regarding status of patch release.  Spoke with Jerome Brown who informed me that Brian Green is the person who I need to speak with regarding the patch release schedule.  Jerome will leave a message with Brian and provide my contact information.

The information captured on the “issues” (or “impediments”) tab would be similar to the “risks” tab, except the information pertains to issues which are already having an impact on your project.  The most important information on this tab should be the level of issue impact and the resolution plan (similar to the mitigation plan) – how the issue will be resolved or how the impact of the issue will be minimized.

The action items tab captures items assigned to project team members not pertaining to actual development activities (these would be represented as “tasks” and captured in the sprint backlog).

The decisions tab captures any decisions made by the Product Owner, stakeholder, or development team, and should include:

• Decision Description
• Decision Made By
• Date of Decision
• Documentation of Decision – I have always insisted that major decisions are documented via email – if it isn’t written down, it doesn’t exist!  I then take the email, save it as a PDF, and store it on a shared drive or network drive where it can be easily accessed and shared with the project team.  So this indicates the location of the documentation of the decision.

The decision tab is basically a “CYA”.  If someone questions a decision (especially the person who MADE the decision), this tab provides evidence of the decision so it isn’t a “he said vs. she said” scenario.

As one of the three pillars of Scrum is transparency, it is essential that this RAID Log is shared with the entire project team, the Product Owner, AND the stakeholder.  Giving visibility of risks to the stakeholder not only shows them all of the current risks that have been identified that may impact your project, but the status of each risk and the implementation of the mitigation plan for that risk.

Being proactive in terms of risk management will show your project team and your stakeholders that you are in control of the project, and better assures that your project will be successfully delivered.