Risk Management in Scrum
Let´s go!
What is Risk Management?
Risk management is the continuous process of identifying, analyzing, prioritizing, and responding to risks in order to reduce their likelihood or impact on a project.
Next
Risk Management in Scrum
In Agile, risk is anything uncertain that could affect your project’s ability to deliver value— whether that impact is negative (a problem) or sometimes even positive (an opportunity).
Instead of trying to eliminate all risk upfront (like in traditional models), Agile assumes risk is inevitable and focuses on managing it continuously throughout development.
Next
How is Risk Understood in Agile?
Unclear requirements → Ex: You might build the wrong feature
Technical challenges → Ex: Integration issue, calling problems, new technologies
Dependencies → Ex: Waiting on other teams or systems
Time and scope pressure → Ex: Not finishing what was planned
Stakeholders → Ex: Late feedback forces rework after sprint completion
Team collaboration → Ex: Dev implements a feature differently from agreed design
External factors → Ex: Market changes, economic shifts, new regulations
Next
Dual Levels of Risk Management
Sprint Level Specific phase risks and tasks
Project levelOverall stability considerations
Next
Risk Management Activities/ Response Planning
Risk prioritization
Risk mitigation
Risk monitoring
Risk identification
Next
Risk Identification Techniques
1.
Brainstorming and collaboration
2.
Learning form the past: Check on historical records
3.
Document analysis
4.
5.
Expertise interviews
Swot and Pestle Analysis
Continuar
Risk Document Analysis
Documentation Technique #1
It is a structured document used to identify, evaluate, prioritize, and track project risks, including their impact, probability, and mitigation plans.
It should include:
- Project requirements
- Technical design
- Historical data
- Contract documents
- Industry standards
- Risk management approach and Risk assessment criteria
- Risk Register
- Mitigation strategies
- Risk Burndown Chart
Continuar
Risk Register
It includes:
Description of the risk
Likelihood and impactResponsible personResponse strategy/MitigationWhy it is important
Continuar
Risk-Value Matrix
Prioritization Technique #1
It is a prioritization tool used to evaluate features or tasks based on:
Risk → uncertainty or potential problems
Value → business or user benefit
It helps teams decide:
- Which high-value items should be prioritized
- Which high-risk items need early attention or mitigation
The goal is to balance business value with project risk during planning. From a QA perspective it identifies where failure would hurt the most.
We can divide risk through categories:
Category 1: High impact, high likelihood
Category 2: High impact, medium likelihood
Category 3: Low impact, high likelihood
Next
Quantitative Risk Exposure Calculation (Time-based)
Example: QA team identifies the following risk. → Risk: Backend integration delay
→ Probability: 50% (0.5)
→ Impact: 8 days of delay (Historically estimated) Calculation → Risk Exposure = 0.5×8 days = 4 days
Result: The quantitative risk exposure is 4 expected days of delay which may be translated to losses in money.
Risk Exposure = Probability × Impact
Continuar
RICE Scoring Model
A QA team must prioritize two features for testing:
Prioritization Technique #2
It is a prioritization technique used to evaluate features, tasks, or risks based on four factors:
Reach → how many users are affectedImpact → how valuable or important it isConfidence → how certain the estimates are
Effort → how much work is required
From a QA perspective, it resolves conflicts when multiple items are important.
Formula:
- Rice Score = (Reach x Impact x Confidence) / Effort
Result: The Login System has a higher RICE score, so it should be prioritized first because it affects more users and delivers higher impact.
Next
MoSCoW Method
Prioritization Technique #3
The MoSCoW Method is a prioritization technique used to classify requirements into four categories:Must Have → critical
Should Have → important
Could Have → optional
Won’t Have → excluded for now
It helps teams prioritize work and manage scope during sprint planning. QA focuses testing on Must have first, if time is limited, could have may not be tested fully.
Next
Risk Census
Documentation Technique #2
It is a structured and centralized list of all identified risks in a project at a specific moment in time. It provides a complete view of uncertainty and is continuously updated as new risks appear or existing ones change.
It is often:
- A summarized view of the risk register
- A reporting perspective of current risks
Next
Risk Burndown Chart
It is a visual representation of how total project risk decreases over time. It is commonly used in Scrum to monitor whether risks are being effectively reduced across sprints.
Components of a risk burndown chart:
- X-axis: time (iterations or sprints)
- Y-axis: total risk exposure (sum of all risks)
- Data points: total risk at each time interval
- Trend line: shows whether risk is decreasing, stable, or increasing
Total initial risk exposure:
20 + 20 + 12 = 52 This value (52) becomes the starting point of the risk burndown chart.
Next
At the end of each sprint:
Update probability and/or impact
Recalculate exposure
Remove resolved risks
Add new risks if identified
A downward trend indicates risks are being reduced
A flat line indicates risks are not being addressed
An upward movement indicates new or worsening risks
+Interpret the result
+Re-evaluate risks each sprint
Continuar
Risk Management Strategies
Each strategy is taken based on:
Understanding the risk tolerance
Apply the appropriate strategy
Continues management
Informed-decision making
Continuar
Risk Mitigation:
Strategies
Risk Mitigation Strategies:
- Training programs and knowledge sharing
- Process Improvements: Adjustments made to workflows, communication, or development practices to increase efficiency and reduce recurring problems.
- Sprint-level risk assessment.
- Technical debt management. (Shortcuts or low-quality implementations that may cause future maintenance issues.)
- Redundancy measures: Practices that ensure critical knowledge or responsibilities are shared among multiple team members to reduce dependency and improve continuity.
- Risk transfer: Strategy of shifting responsibility or impact of a risk to another party.
- Risk acceptance: Strategy of acknowledging a risk and deciding not to take immediate action because the impact is manageable or mitigation is too costly.
Next
VUCA
Framework for understanding and managing uncertainty
It is used to describe environments with high uncertainty and rapid change.
- Volatility → situations change quickly
- Uncertainty → lack of clear information or predictability
- Complexity → many interconnected factors or dependencies
- Ambiguity → unclear meaning, expectations, or outcomes
During sprint planning in Scrum, QA can use VUCA to analyze high-risk stories before committing to them.
Next
Example: Multiplayer synchronization
3. Complexity → Too many interconnected parts
QA action:
- Test components separately (client, server, API)
- Identify integration points
- Focus on high-risk interactions
1. Volatility → Requirements may shift during the sprint
QA action:
- Avoid rigid test cases
- Use exploratory testing
- Keep test cases flexible
2. Uncertainty → You do not fully understand the system
QA action:
- Ask questions during planning
- Request demos or prototypes
- Test early builds as soon as possible
4. Ambiguity → Behavior is not clearly defined
QA action:
- Define acceptance criteria clearly
- Document assumptions
- Confirm expected results with stakeholders
Next
1. Scope: Reduce scope for highly volatile or ambiguous stories
2. Order: Test uncertain or complex features earlier
3. Effort: Allocate more time for high-complexity testing
4. Risk visibility: Clearly communicate which stories are high-risk
VUCABenefits
Based on VUCA analysis, QA can influence:
Continuar
Benefits of Daily Scrum Risk Monitoring
- Early detection
- Increased transparency
- Proactive problem solving
- Adaptive mindset
Continuar
Risk Management in Sprint Review and Retrospectives
- Retrospectives risk management helps to examine potential and materialized issues to adjust accordingly. Using an impact evaluation we can course correct and build a culture of transparency and resilience.
- In the Sprint Planning, we can get stakeholder feedback to identify fresh perspectives, disconnect and build trust.
Anti-Patterns: Ignoring Risks in Favor of Speed
Using proper assessment, analysis and documentation through time, QA can communicate to the team how decreasing speed saves time by preventing risks. Remember, saved time equals to saved money.
Next
Examples of QA in Risk Management
Scope Creep
Technological Debt
Risk management:
- QA participates in sprint planning to understand scope clearly
- Define entry criteria for testing (no testing if requirements are unclear)
- Push for backlog refinement before sprint starts
Contingency plan:
- Re-negotiate testing scope with Product Owner
- Focus only on critical path validation
- Log untested areas as known risks for stakeholders
Risk management:
- Advocate for regression testing every sprint
- Track recurring bugs and flag them as debt
- Collaborate with devs to improve testability
Contingency plan:
- Increase focused regression cycles before release
- Create a “known issues” list for stakeholders
- Prioritize testing around historically fragile areas
A Known Issues Report in QA is a documented list of identified bugs, defects, or limitations in a software product that are acknowledged by the team but will not be fixed before the current release.
Continuar
Conclusion
By employing proper risk management (identification, analysis, documentation, and tracking), QA can help the team to implement better and proactive practices that add value to the project.
Next
Thank you!
Inicio
Factors Affecting Risk Approach and Assessment
- Risk attitude: Organizational approach to risk-taking
- Risk sensitivity: Impact level on project or organization
- Resource availability: Time, budget and talent constraints
- Risk Manageability: Ease or complexity of risk management
Agile Events for Risk Management
These activities may be executed during:
- Backlog refinement
- Sprint planning
- Reviews and retrospectives
Risk Management in Scrum
Valentina Uribe Valencia
Created on May 7, 2026
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Smart Presentation
View
Practical Presentation
View
Essential Presentation
View
Akihabara Presentation
View
Flow Presentation
View
Terrazzo Presentation
View
Dynamic Visual Presentation
Explore all templates
Transcript
Risk Management in Scrum
Let´s go!
What is Risk Management?
Risk management is the continuous process of identifying, analyzing, prioritizing, and responding to risks in order to reduce their likelihood or impact on a project.
Next
Risk Management in Scrum
In Agile, risk is anything uncertain that could affect your project’s ability to deliver value— whether that impact is negative (a problem) or sometimes even positive (an opportunity). Instead of trying to eliminate all risk upfront (like in traditional models), Agile assumes risk is inevitable and focuses on managing it continuously throughout development.
Next
How is Risk Understood in Agile?
Unclear requirements → Ex: You might build the wrong feature Technical challenges → Ex: Integration issue, calling problems, new technologies Dependencies → Ex: Waiting on other teams or systems Time and scope pressure → Ex: Not finishing what was planned Stakeholders → Ex: Late feedback forces rework after sprint completion Team collaboration → Ex: Dev implements a feature differently from agreed design External factors → Ex: Market changes, economic shifts, new regulations
Next
Dual Levels of Risk Management
Sprint Level Specific phase risks and tasks
Project levelOverall stability considerations
Next
Risk Management Activities/ Response Planning
Risk prioritization
Risk mitigation
Risk monitoring
Risk identification
Next
Risk Identification Techniques
1.
Brainstorming and collaboration
2.
Learning form the past: Check on historical records
3.
Document analysis
4.
5.
Expertise interviews
Swot and Pestle Analysis
Continuar
Risk Document Analysis
Documentation Technique #1
It is a structured document used to identify, evaluate, prioritize, and track project risks, including their impact, probability, and mitigation plans.
It should include:
Continuar
Risk Register
It includes: Description of the risk Likelihood and impactResponsible personResponse strategy/MitigationWhy it is important
Continuar
Risk-Value Matrix
Prioritization Technique #1
It is a prioritization tool used to evaluate features or tasks based on: Risk → uncertainty or potential problems Value → business or user benefit It helps teams decide:
- Which high-value items should be prioritized
- Which high-risk items need early attention or mitigation
The goal is to balance business value with project risk during planning. From a QA perspective it identifies where failure would hurt the most.We can divide risk through categories: Category 1: High impact, high likelihood Category 2: High impact, medium likelihood Category 3: Low impact, high likelihood
Next
Quantitative Risk Exposure Calculation (Time-based)
Example: QA team identifies the following risk. → Risk: Backend integration delay → Probability: 50% (0.5) → Impact: 8 days of delay (Historically estimated) Calculation → Risk Exposure = 0.5×8 days = 4 days Result: The quantitative risk exposure is 4 expected days of delay which may be translated to losses in money.
Risk Exposure = Probability × Impact
Continuar
RICE Scoring Model
A QA team must prioritize two features for testing:
Prioritization Technique #2
It is a prioritization technique used to evaluate features, tasks, or risks based on four factors: Reach → how many users are affectedImpact → how valuable or important it isConfidence → how certain the estimates are Effort → how much work is required From a QA perspective, it resolves conflicts when multiple items are important. Formula:
Result: The Login System has a higher RICE score, so it should be prioritized first because it affects more users and delivers higher impact.
Next
MoSCoW Method
Prioritization Technique #3
The MoSCoW Method is a prioritization technique used to classify requirements into four categories:Must Have → critical Should Have → important Could Have → optional Won’t Have → excluded for now It helps teams prioritize work and manage scope during sprint planning. QA focuses testing on Must have first, if time is limited, could have may not be tested fully.
Next
Risk Census
Documentation Technique #2
It is a structured and centralized list of all identified risks in a project at a specific moment in time. It provides a complete view of uncertainty and is continuously updated as new risks appear or existing ones change. It is often:
Next
Risk Burndown Chart
It is a visual representation of how total project risk decreases over time. It is commonly used in Scrum to monitor whether risks are being effectively reduced across sprints. Components of a risk burndown chart:
Total initial risk exposure: 20 + 20 + 12 = 52 This value (52) becomes the starting point of the risk burndown chart.
Next
At the end of each sprint: Update probability and/or impact Recalculate exposure Remove resolved risks Add new risks if identified
A downward trend indicates risks are being reduced A flat line indicates risks are not being addressed An upward movement indicates new or worsening risks
+Interpret the result
+Re-evaluate risks each sprint
Continuar
Risk Management Strategies
Each strategy is taken based on: Understanding the risk tolerance Apply the appropriate strategy Continues management Informed-decision making
Continuar
Risk Mitigation:
Strategies
Risk Mitigation Strategies:
Next
VUCA
Framework for understanding and managing uncertainty
It is used to describe environments with high uncertainty and rapid change.
- Volatility → situations change quickly
- Uncertainty → lack of clear information or predictability
- Complexity → many interconnected factors or dependencies
- Ambiguity → unclear meaning, expectations, or outcomes
During sprint planning in Scrum, QA can use VUCA to analyze high-risk stories before committing to them.Next
Example: Multiplayer synchronization
3. Complexity → Too many interconnected parts QA action:
1. Volatility → Requirements may shift during the sprint QA action:
2. Uncertainty → You do not fully understand the system QA action:
4. Ambiguity → Behavior is not clearly defined QA action:
Next
1. Scope: Reduce scope for highly volatile or ambiguous stories 2. Order: Test uncertain or complex features earlier 3. Effort: Allocate more time for high-complexity testing 4. Risk visibility: Clearly communicate which stories are high-risk
VUCABenefits
Based on VUCA analysis, QA can influence:
Continuar
Benefits of Daily Scrum Risk Monitoring
Continuar
Risk Management in Sprint Review and Retrospectives
Anti-Patterns: Ignoring Risks in Favor of Speed
Using proper assessment, analysis and documentation through time, QA can communicate to the team how decreasing speed saves time by preventing risks. Remember, saved time equals to saved money.
Next
Examples of QA in Risk Management
Scope Creep
Technological Debt
Risk management:
- QA participates in sprint planning to understand scope clearly
- Define entry criteria for testing (no testing if requirements are unclear)
- Push for backlog refinement before sprint starts
Contingency plan:Risk management:
- Advocate for regression testing every sprint
- Track recurring bugs and flag them as debt
- Collaborate with devs to improve testability
Contingency plan:- Increase focused regression cycles before release
- Create a “known issues” list for stakeholders
- Prioritize testing around historically fragile areas
A Known Issues Report in QA is a documented list of identified bugs, defects, or limitations in a software product that are acknowledged by the team but will not be fixed before the current release.Continuar
Conclusion
By employing proper risk management (identification, analysis, documentation, and tracking), QA can help the team to implement better and proactive practices that add value to the project.
Next
Thank you!
Inicio
Factors Affecting Risk Approach and Assessment
Agile Events for Risk Management
These activities may be executed during: