7.

QUALITY & RISK MANAGEMENT

A) Elements of quality in an agile environment

Continuous Improvement
Agile emphasizes on continuous improvement, where feedback is given throughout the
development process, and changes can be made to the product based on this
feedback. Quality is improved by addressing issues as they arise.
Customer Satisfaction
The primary goal of an agile team is to deliver a product that meets the customer's
needs. Quality is determined by how well the product meets the customer's
requirements and expectations.
Collaborative Teamwork
Agile development is all about collaboration and teamwork. Quality is achieved by
having teams that work together, sharing knowledge and skills to achieve common
goals.
Adaptability
Teams need to be adaptable to changes in the project scope, timelines, or customer
needs. Quality is achieved by being flexible and making adjustments as needed to
ensure that the final product meets the requirements.
Delivering Value
Agile teams prioritize the delivery of value to the customer over adhering to a rigid plan.
Quality is achieved by delivering a product that meets or exceeds customer
expectations and provides value.
Testing & Feedback
Agile development emphasizes on testing and feedback as a critical component of
quality. Testing is done continuously throughout the development process, and
feedback is provided by customers and stakeholders to identify issues and make
improvements.
Transparency
Agile teams prioritize transparency and open communication. Quality is achieved by
making all aspects of work visible, transparent in their progress, risks, impediments,
and decision-making processes.

1
7. QUALITY & RISK MANAGEMENT

B) Quality Management

1. Planning and assessing quality in agile projects

Planning and assessing quality in an agile project involves the following steps:
Define quality criteria (Definition of Done): The first step is to define the quality
criteria that the project team will use to assess the product. Quality criteria can include
performance, reliability, usability, security, maintainability, and other requirements.
These criteria should be agreed upon by the entire team, including stakeholders and
customers.
Define acceptance criteria: Acceptance criteria are the specific requirements that the
product must meet to be considered acceptable. These criteria should be written in
collaboration with the customer and stakeholders and should be measurable, specific,
and achievable.
Conduct frequent testing: Testing should be done frequently throughout the project.
The team should conduct automated, exploratory and acceptance testing to ensure
that the product meets the quality criteria and acceptance criteria.
Use metrics to measure progress: The team should use metrics to measure
progress and identify areas for improvement. Metrics can include code coverage,
defect rates, and other quality-related measures.
Conduct peer reviews: Peer reviews are an effective way to identify and correct
issues early in the project. Code reviews, design reviews, and other types of peer
reviews can help the team identify quality issues and make improvements.
Continuously improve: The team should continuously improve their processes to
ensure that they are delivering high-quality products. The team should review their
processes and make changes as necessary to improve quality.

2. Example of quality criteria (Definition of Done)

Definition of Done (DoD)

 Code is reviewed by a peer before being merged into the main branch.
 Automated unit tests and integration tests are written and passed successfully.

2
7. QUALITY & RISK MANAGEMENT

 Manual testing is performed by a tester to validate the functionality and ensure

that it meets the acceptance criteria.
 The feature is integrated with the rest of the website and is tested to ensure that
it does not cause any regressions.
 Documentation is updated to include instructions for how to use the password
reset feature.
 The feature is deployed to the production environment and is monitored to
ensure that it is working correctly.

Acceptance criteria

 The password reset feature should be accessible from the login screen.
 The user should be able to enter their email address to receive a
password reset link.
 The user should be able to click on the password reset link and be taken to a
secure page to reset their password.
 The new password should meet the minimum password strength requirements.
 After the password is reset, the user should be able to log in to their account
with the new password.

4. Overview of the different testing methods in software development

Automated Testing
Automated testing involves using software tools to run tests on the software. It is
typically used for repetitive tasks, such as regression testing, and it can be used to
test software quickly and efficiently. Automated testing is usually done by writing
test scripts that can be run repeatedly to check the software's functionality. It is
highly repeatable, and results can be easily analysed, but it is limited by the fact
that it can only test what it has been programmed to test.

Exploratory Testing
Exploratory testing is a type of manual testing that is performed without a specific
plan or script. Testers use their experience, intuition, and knowledge of the software
to test it in a creative and unscripted way. Exploratory testing is highly flexible and
adaptable, and it can reveal issues that might not be identified through automated
or scripted testing. However, it is difficult to measure and report on results.

Acceptance Testing
Acceptance testing is a type of testing that is usually performed by the customer or
end-user of the software. The goal is to determine whether the software meets the
acceptance criteria, which are typically the requirements specified by the customer
or stakeholders. Acceptance testing is usually performed after the software has
been developed and is in the final stages of testing before release. It is highly
focused on whether the software meets the requirements and specifications, but it
may not catch issues related to usability or performance.

3
7. QUALITY & RISK MANAGEMENT

5. Continuous Integration/Contentious Delivery (CI/CD)

CI/CD (Continuous Integration/Continuous Delivery) is a software development

practice that involves integrating code changes frequently and automatically, testing
them, and then deploying them to production environments. It is a key practice in
DevOps and Agile methodologies.

This image illustrates the DevOps lifecycle, representing a continuous and automated
approach to software development and operations. The infinity loop highlights the
constant feedback and iterative nature of the process. It's broken down into two main
parts: Continuous Integration (CI) and Continuous Delivery/Deployment (CD).

CI: Continuous Integration

The left loop, CI, focuses on the development and testing phase. The goal is to have
developers integrate their code into a shared repository frequently. Each integration is
then automatically verified.

 Plan: The team plans the features and tasks for the upcoming development
cycle.
 Code: Developers write the source code for the planned features.
 Build: The written code is automatically compiled into an executable
application. This is the first step in verifying the code works together.
 Test: Automated tests (unit tests, integration tests) are run against the build to
check for bugs and ensure quality. If tests pass, the build is considered ready for
the next stage.

CD: Continuous Delivery / Continuous Deployment

The right loop, CD, focuses on getting the tested code into the hands of users. The
central "Release" stage is the bridge from CI to CD.

4
7. QUALITY & RISK MANAGEMENT

 Release: The successfully tested build is packaged and versioned, making it a

release candidate ready for deployment.
 Deploy: The release is automatically deployed to various environments, starting
with staging or testing environments and ultimately production.
 Operate: The deployed application is running in the production environment,
serving users. This phase involves managing the infrastructure and ensuring the
service is available.
 Monitor: The team continuously monitors the application's performance,
stability, and user behavior to gather feedback. This feedback flows directly
back into the "Plan" phase of the next cycle.

Key Exam Takeaways

 Goal of DevOps: The primary goal is to shorten the development lifecycle,

delivering high-quality software more frequently and reliably. 🔁
 Automation is Key: Every stage in the loop is a candidate for automation to
increase speed and reduce human error.
 Feedback Loops: The infinity shape emphasizes that this is not a linear process.
Information from the Monitor and Operate phases directly informs
the Plan phase, creating a cycle of continuous improvement.
 CI vs. CD:
o Continuous Integration (CI): Automates the building and testing of
code every time a developer commits changes.
o Continuous Delivery: Extends CI by automatically deploying every
validated build to a testing/staging environment. The final deployment to
production is a manual button-push.
o Continuous Deployment: Goes one step further and automatically
deploys every validated build directly to production without manual
intervention.
 Project Management Impact: DevOps represents a shift from traditional,
phased project management to a more fluid, continuous product development
model. It enables faster delivery of value, reduced risk through smaller,
incremental changes, and data-driven decision-making based on operational
feedback.

Continuous Integration (CI) is the practice of frequently merging code changes

into a shared repository and automatically testing the code to detect integration
issues as early as possible. The idea is to catch issues early, when they are still
small and easy to fix. The testing can be done manually or automatically,
depending on the level of automation in the project.
Continuous Delivery (CD) is the practice of automatically deploying the code
changes to production once they have passed the testing phase. The idea is to
have a repeatable and reliable process for deploying code changes, with minimal
risk of introducing bugs or breaking the production environment.

5
7. QUALITY & RISK MANAGEMENT

6
7. QUALITY & RISK MANAGEMENT

C) Risk Management
1. What is a risk?
A risk is anything that could prevent or marginalize project success - IF it comes to
fruition.
An ISSUE is when a RISK materialises.

2. Types of risks
Based on Rumsfeld framework above, we can identify four types of risks:
Known risks: These are risks that are well-understood and documented, such as
risks that have been identified through past experiences or industry standards.
Predictable risks: These are risks that are known to exist but are difficult to
quantify or predict, such as risks associated with complex systems or emerging
technologies.
Unidentified risks: These are risks that have not been identified or considered,
such as risks that arise from unexpected events or changes in the business
environment.
Unpredictable risks: These are risks that are impossible to foresee or prepare for,
such as natural disasters or geopolitical events.

3. Examples of "typical" project risks

Known Risks
Resource Risks: Resource risks can occur when the project team members lack
the necessary skills or experience to complete the tasks, or when there are
insufficient resources allocated to complete the project.
Schedule Risks: Schedule risks can arise from factors such as poor project
planning, underestimating the time required for specific tasks, or unexpected
delays.
Cost Risks: Cost risks can occur when the project budget is insufficient, or when
there are cost overruns due to unexpected expenses or poor budget management.
Predictable Risks
Technical Risks: Technical risks can arise from the complexity of the project, such
as using new or untested technology or integrating multiple systems.
Stakeholder Risks: Stakeholder risks can arise from factors such as a lack of
stakeholder engagement, miscommunication, or conflicting priorities between
stakeholders.

Unidentified Risks

7
7. QUALITY & RISK MANAGEMENT

Legal and Regulatory Risks: Legal and regulatory risks can arise from non-
compliance with laws and regulations or legal issues related to intellectual property
or contracts.
Security Risks: Security risks can arise from a lack of data protection,
cybersecurity threats, or hacking attacks that can compromise the project's
integrity.
Unpredictable Risks
Environmental Risks: Environmental risks can occur when a project has the
potential to harm the environment or cause negative social impacts.

4. Principles of Risk Management

This image shows a 5-step Risk Management Process, a fundamental framework in

project management for handling uncertainty.

The 5 Steps of Risk Management

1. Identify: This is the first step where the project team brainstorms and
documents potential risks that could positively or negatively affect the project.
This is often done by creating a risk register. 🔁
2. Prioritize (or Analyze): Once risks are identified, they are assessed to
determine their potential impact on the project and their probability of occurring.
This analysis helps the team focus on the most critical risks instead of trying to
address everything. A common tool for this is a probability and impact
matrix.
3. Mitigate (or Treat): For high-priority risks, the team develops response plans.
The goal is to create strategies to reduce the likelihood or impact of threats and
to enhance the chances of opportunities. Common strategies include avoiding,
transferring, mitigating, or accepting a risk.
4. Monitor: This is an ongoing process of tracking the identified risks, looking for
any new risks that may arise, and evaluating the effectiveness of the risk
response plans. This is not a one-time activity but continues throughout the
project's lifecycle. 🔁
5. Adapt (or Control): Based on monitoring, the team adjusts its plans. If a
mitigation strategy isn't working or if a risk's priority changes, the team adapts
its approach. This step ensures the risk management process is a dynamic,
learning loop, not a static plan.

8
7. QUALITY & RISK MANAGEMENT

Key Exam Takeaways

 Proactive, Not Reactive: This framework is designed to proactively manage

uncertainty rather than reactively fighting fires.
 Cyclical Process: The process is continuous. The "Adapt" step feeds back into
the "Identify" step, creating a cycle of ongoing risk management throughout the
project.
 Core PM Function: Risk management is a core responsibility of a project
manager and is integral to all project phases, from initiation to closing.

Identify
The first step in Agile risk management is to identify potential risks. This can be
done at the start of the project and continuously throughout the project.
Prioritize
Once the risks have been identified, the team must prioritize them based on their
potential impact on the project's objectives. The team can use various techniques
to prioritize risks, such as a risk matrix, where the likelihood and impact of each risk
are assessed.
Mitigate
The team must then develop and implement risk mitigation strategies for the high-
priority risks. In Agile, the team typically focuses on mitigating the most critical risks
first.
Monitor

After implementing the mitigation strategies, the team must monitor the risks to
ensure they remain under control. This is done by tracking the risks throughout the
project and assessing their impact as the project progresses.
Adapt
Agile is built on the idea that change is inevitable, so the team must be prepared to
adapt their risk management strategies as the project evolves. This means
continuously reassessing risks, updating the mitigation strategies, and being
responsive to changes in the project's objectives or environment.

5. Popular methods for identifying risks

Brainstorming: Brainstorming sessions are a simple and effective way to identify
potential project risks. The team can come together to identify potential risks and
document them.
SWOT Analysis: SWOT (Strengths, Weaknesses, Opportunities, and Threats)
analysis can be used to identify potential project risks by analysing the project's
strengths and weaknesses and identifying external opportunities and threats.

9
7. QUALITY & RISK MANAGEMENT

This image displays a SWOT Analysis Matrix, a foundational strategic planning tool
used in business and project management.

Deconstructing the SWOT Matrix

SWOT is an acronym that stands for Strengths, Weaknesses, Opportunities, and

Threats. The matrix organizes these factors along two
dimensions: Internal/External and Helpful/Harmful.

1. Strengths (S)
o Internal & Helpful: These are the positive attributes and
resources within the organization or project team. They are advantages
that you have some control over.
o Examples: A skilled project team, a strong brand reputation, proprietary
technology, or access to capital.
2. Weaknesses (W)
o Internal & Harmful: These are the negative factors or areas for
improvement within the organization. They are disadvantages that can
hinder performance.
o Examples: Lack of expertise, limited budget, outdated technology, or
poor internal processes.
3. Opportunities (O)
o External & Helpful: These are positive factors or favorable trends in
the external environment that the project or organization could leverage
to its advantage.
o Examples: A new emerging market, competitor weakness, favorable
government regulations, or new technology trends.
4. Threats (T)
o External & Harmful: These are negative factors or risks in the external
environment that could jeopardize the project's success.
o Examples: New competitors, a market downturn, unfavorable
regulations, or supply chain problems.

10
7. QUALITY & RISK MANAGEMENT

Key Exam Takeaways

 Purpose: A SWOT analysis is used during the initiation and planning

phases of a project to assess its viability and to inform strategic decisions. It
provides a comprehensive snapshot of the project's position.
 Informing Strategy: The results are used to develop strategies. For example, a
team might use its Strengths to capitalize on Opportunities or develop plans to
mitigate Threats.
 Input for Risk Management: The Weaknesses and Threats identified in a
SWOT analysis are direct inputs into the project's risk register and risk
management plan.

User Stories: User stories can be used to identify potential project risks from the end-
user's perspective. User stories can help identify scenarios that may pose risks to the
project.
Retrospectives: Retrospectives are meetings held at the end of each iteration to
reflect on the process and identify areas for improvement. They can also be used to
identify potential project risks and develop strategies to address them in future
iterations.

6. Frequently used risk prioritization techniques

Risk Assessment Matrix: A risk assessment matrix is a tool that can be used to
assess and prioritize identified risks based on their likelihood and impact. The risks are
plotted on a matrix that considers their likelihood of occurrence and the impact they
would have on the project. Risks that are deemed high probability and high impact
should be given the highest priority for mitigation.

Deconstructing the Risk Matrix

The purpose of this matrix is to classify risks based on two key dimensions to determine
their overall severity and priority.

1. Likelihood (Y-Axis): This vertical axis measures the probability that a risk will
occur. In this example, it's broken down into four percentage-based ranges (e.g.,
76-100% means the risk is very likely to happen).

11
7. QUALITY & RISK MANAGEMENT

2. Impact (X-Axis): This horizontal axis measures the severity of the

consequences if the risk does occur. Here, it's defined by qualitative categories:
Minor, Moderate, Major, and Critical.

Interpreting the Data and Color-Coding

The numbers in each cell represent the quantity of risks that fall into that specific
category. The color of the cell indicates the overall risk level, which helps in prioritizing
response efforts.

 Red (High Risk): These are the most severe risks that demand immediate
attention and proactive management plans. In this matrix, there are 2 risks with
a Critical impact and a high likelihood (76-100%). These are the project's top
priorities.
 Yellow (Medium Risk): These risks are significant and should be monitored
closely. Mitigation plans might be developed for them. The 5 risks with
a Major impact and medium likelihood (51-75%) are a good example.
 Green (Low Risk): These risks have a low probability, a low impact, or both.
They may not require a specific response plan beyond being documented in the
risk register. The 12 risks with Moderate impact and low likelihood (0-25%)
fall into this category.

Key Exam Takeaways

 Purpose: The primary purpose of a Risk Matrix is to prioritize risks so that the
project team can focus its limited time and resources on addressing the most
significant threats.
 Qualitative Analysis: This is a tool for qualitative risk analysis. It uses
descriptive scales (Minor, Major) and ranges rather than precise monetary
values.
 Visual Communication: It provides a simple, powerful visual summary of the
project's risk landscape, which is easy to communicate to stakeholders.
 Input for Action: The output of this analysis directly informs the "Mitigate" (or
Risk Response Planning) phase. The risks in the red and yellow zones will be
the first ones for which the team develops action plans.

Cost of Delay: The cost of delay is a technique used to prioritize risks by calculating
the cost of delaying action to mitigate the risk. This technique helps the team to identify
the potential losses if the risk is not addressed immediately.

7. FOUR common risk mitigation strategies

Risk mitigation is the process of taking actions to reduce the likelihood or impact of a
risk. Here are some typical risk mitigation strategies in project management:

12
7. QUALITY & RISK MANAGEMENT

This image displays a Risk Response Strategy Matrix. It's a tool used in the
"Mitigate" (or Risk Response Planning) phase of risk management to help decide on the
best course of action for dealing with identified negative risks (threats). The matrix
maps four common strategies against the risk's probability and impact.

Deconstructing the Risk Response Matrix

The matrix uses the same axes as a standard risk matrix—Probability and Impact—to
recommend a strategy for each quadrant.

1. Avoid (High Probability, High Impact)

o Strategy: This strategy is for the most dangerous risks. The goal is to
eliminate the threat entirely by changing the project plan. This might
involve changing the project scope, adjusting the schedule, or altering
the technical approach so the risk can no longer occur.
o Example: If building in a specific flood-prone area is a high-impact/high-
probability risk, the team might avoid it by choosing a different location
for construction.
2. Reduce (High Probability, Low Impact)
o Strategy: Also known as Mitigate. The goal is to take proactive steps to
decrease either the probability of the risk occurring or its impact if it
does. This is one of the most common strategies.
o Example: If there's a high probability of minor software bugs causing
delays, the team can reduce the risk by implementing a more rigorous
code review and testing process.
3. Transfer (Low Probability, High Impact)
o Strategy: This strategy involves shifting the financial consequences of a
risk to a third party. It doesn't eliminate the risk itself, but it protects the
project from its financial impact.
o Example: A project can transfer the risk of damage to expensive
equipment by purchasing insurance. If the equipment is damaged (a low-
probability, high-impact event), the insurance company bears the cost.
Outsourcing a specific high-risk component of the project is another
form of transference.

13
7. QUALITY & RISK MANAGEMENT

4. Accept (Low Probability, Low Impact)

o Strategy: For risks that have a very low probability and/or a very low
impact, the most cost-effective solution may be to do nothing. This is a
conscious decision to accept the risk. It can be active (setting aside a
contingency reserve) or passive (simply documenting the risk and taking
no action).
o Example: The risk of a key team member winning a small lottery prize
and leaving the project is so low that the team would likely just accept it
without a specific action plan.

Key Takeaways

 Purpose: This matrix provides a framework for selecting the appropriate

response strategy for negative risks (threats) based on their priority.
 Context for Risk Management: This tool is used after risks have been
identified and prioritized (using a tool like the Probability and Impact Matrix).
It's a key part of the "Plan Risk Responses" process.
 Positive vs. Negative Risks: Remember that these four strategies (Avoid,
Reduce/Mitigate, Transfer, Accept) are for threats. Positive risks
(opportunities) have a corresponding set of strategies: Exploit, Enhance, Share,
and Accept.

Avoid: This involves eliminating the risk by avoiding the activity that would create it.
Transfer: This involves transferring the risk to a third party.
Reduce: This involves reducing the likelihood or impact of the risk through actions
such as contingency planning or increased quality assurance.
Accept: This involves accepting the risk and making a decision to move forward with
the project despite the risk.
It's important to note that each risk mitigation strategy has its own advantages and
disadvantages, and the most effective strategy will depend on the specific context of
the project and the risk involved. A combination of different strategies may also be used
to address different risks.

8. Risk Management in Scrum

In Scrum, risk management is an integral part of the development process and is
addressed throughout the three main Scrum ceremonies:
Sprint Planning: The Scrum team identifies the tasks to be completed during the
sprint and evaluates the potential risks that could impact the sprint's objectives. The
team then develops a mitigation plan that outlines the actions to be taken to reduce the
impact of potential risks.
Daily Scrum: The daily Scrum meeting provides a forum for the team to discuss any
risks that have arisen during the sprint and determine the appropriate course of action

14
7. QUALITY & RISK MANAGEMENT

to address them. The Scrum Master may also facilitate discussions around risk
management, helping the team to stay on track and take the necessary actions to
mitigate risks.
Sprint Review: The Scrum team reviews the work completed during the sprint and
evaluates whether the objectives were met. This review provides an opportunity to
identify any risks that emerged during the sprint, assess their impact on the project,
and develop strategies to mitigate them in the next sprint.
In addition to these three main phases, Scrum also includes other risk management
practices, such as:
Retrospectives: The Scrum team holds a retrospective at the end of each sprint to
reflect on the process and identify areas for improvement. This meeting can also be
used to identify potential risks that arose during the sprint and to develop strategies to
address them.
Product Backlog Refinement: The Scrum team reviews the product backlog regularly
to ensure that it remains relevant to the project objectives. This process can also be
used to identify potential risks that could impact the project and to develop strategies to
mitigate them.

15