HKSM

Collaborative tools and methods used in Scrum to evaluate the probability, impact, exposure, and urgency of identified risks, then prioritize responses within the product backlog. Techniques include probability-impact scoring, risk exposure, categorization, EMV for financial risks, and a risk burndown to track reduction across sprints.

Key Points

• Used to score, rank, and visualize risks so the Scrum Team can decide which to address first.
• Lightweight and iterative, applied during release planning, sprint planning, and ongoing Scrum events.
• Combines qualitative scoring (probability-impact matrix, urgency) with simple quantitative checks like EMV where relevant.
• Produces actionable outputs such as mitigation tasks, spikes, and updated acceptance criteria in the product backlog.
• Enables a risk burndown chart to show remaining exposure across sprints.
• Facilitated by the Scrum Master; prioritization decisions are owned by the Product Owner with team input.
• Addresses both threats and opportunities to improve value delivery.

Purpose of Analysis

Risk assessment ensures the team understands which uncertainties could most affect value, scope, cost, time, and quality. The results drive backlog ordering and guide the choice of mitigation strategies such as spikes, prototypes, or additional testing.

It also aligns actions with stakeholder risk appetite and thresholds, making risk handling visible and testable within each sprint.

Method Steps

1. List risks: Gather threats and opportunities from the product backlog, sprint goal, architecture, dependencies, and stakeholders.
2. Define scales: Agree on simple 1-5 scales for probability, impact, and optionally urgency/proximity and detectability.
3. Score and rank: Estimate probability and impact collaboratively; compute exposure (e.g., P x I) and place items on a probability-impact matrix.
4. Categorize: Group by source or category (e.g., technical, external, organizational) to find patterns and systemic issues.
5. Select responses: Choose strategies (avoid, mitigate, transfer, accept; or exploit, enhance, share, accept for opportunities) and define triggers.
6. Create backlog work: Add mitigation tasks, spikes, tests, or guardrails into the product backlog with clear acceptance criteria.
7. Track and review: Assign risk owners, update a risk burndown, and revisit ratings during standups, reviews, and retrospectives.

Inputs Needed

• Product vision, release goals, and current sprint goal.
• Prioritized product backlog, epics, and user stories with initial estimates.
• Stakeholder risk appetite and thresholds, constraints, and compliance needs.
• Historical data, lessons learned, and reference class information.
• Technical context such as architecture decisions, integrations, and dependencies.
• Team capacity, velocity trends, and definition of done and ready.

Outputs Produced

• Ranked risk list with probability, impact, exposure, urgency, category, triggers, and owners.
• Risk responses embedded as backlog items (spikes, test work, safeguards) and updated acceptance criteria.
• Risk-adjusted backlog ordering reflecting both value and exposure reduction.
• Risk burndown chart showing remaining exposure by sprint.
• Updates to plans and agreements, such as contingency reserves or changes to the definition of done.

Interpretation Tips

• Use ordinal scales consistently; avoid false precision when data is limited.
• Focus on comparative ranking to drive action rather than perfect accuracy.
• Reassess frequently; risk exposure can rise or fall as new information appears.
• Pair high-exposure risks with clear, testable mitigation tasks linked to backlog items.
• For financial or contractual risks, complement qualitative scores with EMV and simple what-if analysis.

Example

During release planning, the team identifies integration uncertainty with an external API. They score probability as 4 and impact as 5, making it a top-ranked threat. The Product Owner adds a spike to prototype the integration and defines acceptance criteria to validate authentication and rate limits.

By the next sprint review, the spike reduces uncertainty; the team lowers the probability to 2 and updates the risk burndown, showing a clear drop in exposure. Related user stories are reordered earlier to address remaining edge cases.

Pitfalls

• Relying on one expert and skipping team-based estimation, leading to bias.
• Rating risks without clear scales, causing inconsistent scores across sprints.
• Focusing only on threats and ignoring opportunities that could accelerate value.
• Creating a risk list but not converting responses into backlog items with owners.
• Over-engineering the analysis with heavy models that slow down decisions.
• Letting the risk register go stale and not updating the risk burndown.

PMP/SCRUM Example Question

During sprint planning, the team flags a high-exposure dependency on a third-party library. Which action best applies risk assessment techniques in a Scrum/SBOK context?

1. Add the risk to a register and plan to review it at the end of the release without changing the backlog.
2. Ask the Scrum Master to track the risk privately to avoid alarming stakeholders.
3. Create a timeboxed spike in the product backlog to test the library, assign a risk owner, and update the risk burndown.
4. Delay addressing the risk until velocity improves after a few sprints.

Correct Answer: C — Create a timeboxed spike in the product backlog to test the library, assign a risk owner, and update the risk burndown.

Explanation: Scrum treats risk responses as backlog work. A spike reduces uncertainty, assigns ownership, and allows tracking exposure with a risk burndown. The other options defer action or hide the risk.