HKSM

Mitigated Risks are identified risks whose probability and/or impact have been reduced by executing agreed response actions. They are recorded with updated ratings, residual or secondary risks, and used as inputs for ongoing communication, monitoring, and planning in Scrum.

Key Points

• Output of the Risk Mitigation process; input to Risk Communication and Risk Monitoring.
• Recorded in the risk register and reflected on the risk burndown chart.
• Include updated probability, impact, residual risk, and any secondary risks created by the response.
• May trigger updates to the product backlog, acceptance criteria, or Definition of Done.
• Each mitigated risk has a named risk owner responsible for continued tracking.
• Reviewed in Daily Standup, Sprint Review, and Retrospect to confirm effectiveness.

Purpose

Mitigated risks show the effect of actions taken to reduce exposure, helping the team confirm whether the response worked and what uncertainty remains. They provide evidence for stakeholders, guide future decisions, and maintain visibility through the life of the product or release.

By tracking these items, the team can adjust reserves, refine estimates, and re-order backlog items when risk levels fall or new risks appear.

Key Terms & Clauses

• Risk register: The single source where risks, responses, owners, and status are logged.
• Mitigation strategy: Actions that reduce probability and/or impact without eliminating the risk.
• Residual risk: The remaining exposure after the mitigation is implemented.
• Secondary risk: A new risk introduced by the chosen response action.
• Risk owner: Person accountable for monitoring the risk and the response plan.
• Risk burndown chart: Visual showing total risk exposure trending over time.
• Risk threshold: The agreed level of exposure the stakeholders are willing to accept.

How to Develop/Evaluate

1. Identify and assess the risk, estimating probability and impact using the team’s agreed scale.
2. Select a response (mitigate, avoid, transfer, accept); for mitigation, define concrete actions and success criteria.
3. Create response tasks or spikes in the product or sprint backlog and assign a risk owner.
4. Implement the response during a sprint and capture evidence (tests, measures, prototypes).
5. Reassess probability and impact and update the risk register with residual and secondary risks.
6. Update the risk burndown chart and communicate status in Scrum events.
7. Decide if exposure is now below the risk threshold; if yes, mark as mitigated and continue to monitor.
8. If exposure remains high, iterate on the response or escalate for additional actions.

How to Use

Use mitigated risks as inputs to Risk Communication and Risk Monitoring to maintain transparency and verify that exposure continues to trend down. Share updates in Daily Standup and Sprint Review to inform stakeholders and support decision-making.

Feed the results into backlog refinement and Sprint Planning. Lower exposure may reduce buffer needs or allow reprioritization, while new secondary risks may add new user stories or tasks. Incorporate learning into Retrospect Sprint to improve future risk responses.

Example Snippet

• ID: R-23 — Unauthorized access via API.
• Before mitigation: Probability High (0.6), Impact High (13 story points of rework), Exposure 7.8.
• Response: Add rate limiting, strengthen auth, and perform security test spike.
• After mitigation: Probability Low (0.2), Impact Medium (5 points), Residual Exposure 1.0.
• Secondary risk: Performance degradation due to rate limiting (added as new risk R-41).
• Links: Sprint backlog tasks SB-118, SB-121; Owner: Dev Lead; Status: Mitigated, monitor next two sprints.

Risks & Tips

• Do not mark a risk as mitigated without measurable evidence and updated ratings.
• Always check for secondary risks created by the response and add them to the register.
• Keep a named owner; unowned risks often drift and silently re-emerge.
• Avoid one-time fixes; verify in later sprints to ensure the exposure stays low.
• Reflect major mitigation work in backlog items, acceptance criteria, or Definition of Done.
• Update the risk burndown chart consistently to visualize trend and support governance.

PMP/SCRUM Example Question

After the team completes security hardening tasks to mitigate a high-risk user story, what should the Scrum Master and Product Owner do next?

1. Close the risk and delete all related entries from the risk register.
2. Stop monitoring the risk because mitigation actions were completed.
3. Update the risk register and risk burndown with new ratings, record any residual/secondary risks, and continue monitoring.
4. Escalate to the sponsor to approve additional funding before reporting status.

Correct Answer: C — Update the risk register and risk burndown with new ratings, record any residual/secondary risks, and continue monitoring.

Explanation: After mitigation, the team must reassess exposure, document residual and secondary risks, and keep monitoring. Closing or ignoring the risk prematurely reduces transparency and control.