Assessing Risks in the Scrum Framework

Software Risk Management (SRM) combines a set of tools, processes, and methods for managing risks in the software development lifecycle. In SRM, we want to make informed decisions about what can go wrong at various levels within a company (e.g., business, project, and software related).

What Is Software Risk?

Risk is the potential for loss that may or may not occur in the future. This potential is based on the probability of occurrence and the impact on the business/project and software (time delay, financial loss, performance reduction, reputation loss, etc.).

The Five Phases of an SRM Process

An SRM process will usually include five core phases, the phases are:

Phase 1: Risk identification

The first and most crucial stage of the entire process is identifying the risks that may arise as part of the development process.

Phase 2: Risk analysis

In this phase, the team determines the risk level for each item identified. The likelihood of the risk determines the level of risk to occur and its impact on the user.

As part of the analysis process, I instruct my teams to follow simple guiding questions. This allows them to gain the required data to determine the impact and probability and then prioritize the mitigation steps to limit the risk. Here are some of the core questions:

§ What reasons (design issue, unclear requirements, logical error, etc.) triggered the risk?

• How does this risk affect business reputation, share price, and early commitments?
• How does the risk affect the project resources, timelines, and testing effort?
• How does the risk affect critical aspects of the application (performance, user experience, etc.)?
• What value will we have if we mitigate the risk?
• What is the potential (probability) the risk will materialize?
• What is the impact of this risk occurring?
• What is the impact of fixing this risk (change in design, additional testing)?

Phase 3: Mitigation

A plan is created and implemented based on the analyzed information to handle each risk with a corresponding set of actions.

Phase 4: Track/Monitor

Track the set of decisions and actions that were issued.

Phase 5: Control

Fixing any deviations that occurred at the implementation stage.

Risk Sources in Development Projects

In Agile projects, both the business and engineering teams must deal with risks arising from three possible categories:

Known risks

In this case, the risks are known and become a fact that is transparent to all stakeholders. In addition, known risks are the easiest ones for the team to handle, as they can create a mitigation plan at the start of the project and avoid any negative surprises. Let’s see some examples of such risks:

• Lack of resources to work on the project.
• Lack of automated frameworks to support the testing effort.
• Lack of knowledge and experience of developers.

Known risks with low probability

These Risks are known, and the team is aware of their existence. However, the team is not aware of whether the risk will occur in the project or not. Let’s see some examples of such risks:

• The use of a new technology that is not yet proven to be stable enough is mandatory in certain development activities.
• An unresponsive customer means there is a risk that the team will not get the feedback they need to deliver the right product.
• Working with an external supplier may cause major delays if not delivered on time.

Unknown risks

These risks are a disaster waiting to happen or what I love to call a “Ticking Bomb.” Unknown risks are dangerous as the business has no idea of their existence and where and when they will appear.

Types of Risk in Software Projects

This section will provide examples related to the various kinds of risks associated with software projects.

Risks that influence the business and project timelines

• Risks related to a misunderstanding of project complexities.
• To secure a contract with the customers, the project timelines are cut to affect software quality.
• Lack of customer feedback and ambiguous customer requirements.
• Risks related to wrong budget estimations.
• Improper resource allocation or underutilization of the current resources.
• Risk related to internal politics that influence the project flow.
• Lack of collaboration between key stakeholders involved in the project (e.g., customer, management, development teams, etc.).
• Failure to address priority conflicts throughout the project.
• Lack of project planning causes development and testing gaps.

Technical and technology-related risks

• Risks related to poor product design affect the software’s technical aspects (coding, testing, etc.).
• Continuously changing requirements that add major technical risks.
• Lack of knowledge of the development team related to the technology used in the project.
• Lack of training in an unfamiliar technology used in the development process.
• Use of new/unreliable/unstable technology as part of the development process.
• Third-party tools/frameworks that failed to provide the expected solution.

Risks related to the development team

• Testing and development activities are dependent on external resources.
• Tight timelines affect resource productivity.
• Risks related to HR aspects of team members (e.g., lack of commitment, low motivation, lack of confidence, etc.).
• Risks related to low-quality engineering practices (e.g., code reviews, the use of wrong design patterns, testing practices, etc.).
• Teams that are behind schedule and hope to catch up without reporting it.

Assessing Risks in the Scrum Framework

In Scrum projects, we can use the same SRM techniques used in traditional projects to reduce the risks to an acceptable level. However, due to the rapid releases and the high rate of change, we need to adjust those techniques to be more suitable for the Scrum framework.

The use of the SRM process assists the team in designing a test strategy, identifying quality risks, and estimating the effort required to reduce those risks.

In Scrum projects, quality risk analysis takes place in three main places (although it can be used in many other activities as well):

1. Release planning – As part of the release planning, there is a high-level review of the features involved in the release, which makes it a perfect time for different stakeholders to share their technical, business, and project risks. Once the risks are identified, the team can start working on a mitigation plan and a high-level test/development strategy.
2. Sprint planning – The whole team works together to plan the upcoming sprint. During this process, the team identifies and assesses quality risks that will directly impact which stories are added to the sprint backlog and what their estimates are.
3. Sprint retrospective – At the end of this meeting, the team generates a list of impediments that will be prioritized. The SRM process fits perfectly here, as it allows the team to prioritize the impediments based on the risk they add and their impact on the team.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile