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.

In this Ad hoc testing tutorial, let’s deep dive into what Ad hoc testing is, its advantages, disadvantages, types, characteristics, and their best practices.

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.

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.

In this Data driven testing tutorial, let us deep dive into what data driven testing is, its pros & cons, its types, data driven testing in an agile environment, benefits, and their best practices.

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.