HKSM

Identified Risks are the documented list of uncertain events or conditions that could affect product, release, or sprint objectives. Captured during risk identification and updated continuously, they provide input to risk assessment, mitigation planning, and the risk burndown chart.

Key Points

• Output of Identify Risks and an input to Assess Risks and Plan Risk Responses in SBOK.
• Maintained in a risk register as a living list throughout the project and each sprint.
• Each entry typically includes cause-event-effect, triggers, owner, and initial probability-impact.
• Different from impediments or issues, which are problems already happening.
• Linked to user stories, tasks, and acceptance criteria to drive mitigation work.
• Reviewed in backlog refinement, Sprint Planning, Daily Standup, Sprint Review, and Retrospect.

Purpose

Identified Risks make uncertainty visible early so the Scrum Team and Product Owner can prioritize, plan responses, and reduce exposure. The list helps shape release and sprint planning, guides spikes or mitigation tasks, and supports informed trade-offs.

By continuously updating the list, teams can track exposure trends on the risk burndown chart and take timely actions before risks become impediments.

Key Terms & Clauses

• Risk statement: cause-event-effect wording that clarifies what could happen and why.
• Risk owner: person accountable to monitor triggers and coordinate the response.
• Trigger: indicator or condition signaling a risk may occur.
• Probability and impact: qualitative scales or simple scores used for quick prioritization.
• Risk exposure: a combined view of probability and impact to rank risks.
• Response strategies: avoid, mitigate, transfer, accept for threats; exploit, enhance, share for opportunities.
• Risk burndown chart: visual tracking of total risk exposure over time.

How to Develop/Evaluate

Hold short Identify Risks discussions during release planning and backlog refinement, and capture new risks anytime, including in Sprint Planning and Daily Standup. Involve the Scrum Team, Product Owner, Scrum Master, and relevant stakeholders.

Use techniques like brainstorming, checklists, assumptions analysis, dependency mapping, RBS categories, and spikes. For each risk, document a concise statement, owner, trigger, and a quick probability-impact rating; note a draft response if obvious.

Reevaluate top risks at least once per sprint. Merge duplicates, split vague risks, and close risks that are no longer applicable.

How to Use

Feed Identified Risks into qualitative assessment to prioritize which ones need responses now. Convert high-exposure items into mitigation user stories or tasks and place them in the Product Backlog or Sprint Backlog as appropriate.

Adjust backlog ordering when risk reduction has clear value, add risk-based acceptance criteria, and schedule spikes to explore unknowns. Track progress on the risk burndown chart and move realized risks to the impediment or issues log.

Review status in Sprint Review for transparency and capture learning in the Sprint Retrospect.

Example Snippet

• API contract may change mid-sprint causing rework. Owner: Dev lead. Trigger: vendor release notice. P: Medium, I: High. Response: mitigate by adding wrapper and monitoring vendor calendar.
• Test data not available in staging. Owner: QA. Trigger: staging refresh scheduled. P: High, I: Medium. Response: avoid by coordinating refresh date and creating synthetic data set.
• Key stakeholder unavailable for backlog clarifications. Owner: Product Owner. Trigger: planned travel. P: Medium, I: Medium. Response: transfer by delegating proxy and preparing story clarifications in advance.

Risks & Tips

• Do not confuse risks with impediments; risks are uncertain, impediments are current blockers.
• Avoid bloated entries; capture only the fields needed to decide and act.
• Assign an owner for every risk to ensure triggers are monitored and responses are executed.
• Include positive risks; opportunities can be exploited to deliver more value.
• Link mitigation tasks to related user stories to make the work visible and testable.
• Re-score regularly; stale ratings hide emerging exposure.

PMP/SCRUM Example Question

During backlog refinement, the team notes that a third-party service may deprecate an endpoint next month, which could affect several upcoming user stories. What should the Scrum Master and Product Owner do next?

1. Add it to the impediment log and resolve it after it occurs.
2. Remove the affected user stories from the Product Backlog to avoid the risk.
3. Record it as an identified risk with owner and initial score, and add a mitigation task or spike to the Product Backlog.
4. Wait until the Sprint Retrospect to discuss options with stakeholders.

Correct Answer: C — Record it as an identified risk with owner and initial score, and add a mitigation task or spike to the Product Backlog.

Explanation: The appropriate action is to capture the risk, assign ownership, and plan a response through backlog items. Impediment logs are for realized issues, and delaying action increases exposure.