Assessing Risks in 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.

David Tzemach

January 11, 2026

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.

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):

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.
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.
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.

Author

David Tzemach

Blogs: 55

David Tzemach is a software quality and engineering leader with 19+ years of experience in software testing, quality assurance, and large-scale R&D operations. He specializes in building QA organizations from scratch, defining quality frameworks, and implementing agile and shift-left testing practices across enterprise environments. David has served as Head of QA and QA Architect, authored multiple books on agile quality and testing, and actively contributes to the testing community through his QualityBreach platform and publications.