HKSM

Collaborative methods used by Scrum teams to discover uncertainties that could affect objectives, including threats and opportunities. Applied in release and sprint events to build an initial list of risks, triggers, and owners that feeds the risk register and backlog decisions.

Key Points

• A toolbox of collaborative practices such as brainstorming, prompt lists, assumptions analysis, interviews, Delphi, SWOT, and user story walkthroughs.
• Used continuously at project start, during release planning, backlog refinement, sprint planning, and whenever significant change occurs.
• Covers both negative risks (threats) and positive risks (opportunities).
• Produces clear risk statements, likely triggers, provisional owners, and initial response ideas.
• Facilitated by the Scrum Master; the Product Owner aligns identified risks with product value and backlog priorities.
• Feeds the risk register and may create mitigation stories, spikes, and updates to acceptance criteria or Definition of Done.

Purpose of Analysis

Surface uncertainties early so the team can make informed trade-offs, protect value, and exploit beneficial opportunities. Create a shared, structured list of risks that guides subsequent assessment, prioritization, and response planning within the Scrum cadence.

Method Steps

1. Plan the session: define scope and timebox, choose techniques, prepare a risk prompt list, and invite the right participants.
2. Collect context: vision, epics, key user stories, dependencies, constraints, architecture notes, and historical lessons learned.
3. Generate ideas: use facilitated brainstorming, round-robin, silent writing, and interviews; apply prompt list categories to widen coverage.
4. Walk through backlog and workflow: story-by-story and interface-by-interface, ask what could go wrong or go better.
5. Record risks: write clear cause-risk-effect statements, note triggers and affected items, and tag category and timeframe.
6. Cluster and de-duplicate: group similar risks, validate understanding, and assign a provisional owner for each risk.
7. Update artifacts: add entries to the risk register; create mitigation or exploration spikes in the product backlog; update criteria if needed.
8. Communicate and follow up: share outputs, align with prioritization, and schedule qualitative analysis and tracking.

Inputs Needed

• Product vision, personas, and business goals.
• Prioritized product backlog with epics and key user stories.
• Constraints, policies, compliance requirements, and external dependencies.
• Architecture overview, interfaces, and vendor or API information.
• Historical risks, checklists, and lessons learned from similar efforts.
• Team agreements, Definition of Ready, and Definition of Done.

Outputs Produced

• Updated risk register with identified risks, triggers, categories, and provisional owners.
• Initial response ideas and follow-up actions for later analysis.
• Backlog updates such as mitigation stories, spikes, or reordered priorities.
• Updates to assumptions and constraints logs and acceptance criteria where relevant.
• Inputs for future tracking tools such as a risk burndown chart.

Interpretation Tips

• Describe each risk as an uncertain event with cause and effect, not as a current issue.
• Link risks to specific backlog items, releases, or dependencies to drive concrete action.
• Capture opportunities alongside threats to maximize value.
• Avoid premature scoring; focus on discovery and clarity before analysis.
• Write measurable triggers or early warning signs to aid ongoing monitoring.
• Revisit identified risks each sprint to keep the list fresh and actionable.

Example

During release planning, the Scrum Master facilitates a 45-minute risk workshop. Using a prompt list, the team identifies a threat: third-party API rate limits may block peak traffic.

They log the risk with a trigger (spike in 429 errors), assign a provisional owner, and add a spike story to test throughput and caching. The Product Owner adjusts priorities to schedule the spike early in the release.

Pitfalls

• Inviting only developers and missing key stakeholders such as operations, security, or legal.
• Focusing only on technical threats and ignoring product, vendor, or compliance risks.
• Jumping straight to solutions and skipping clear risk statements and triggers.
• Vague, generic risks that cannot be linked to action or backlog items.
• Treating risk identification as a one-time kickoff activity instead of continuous practice.
• Ignoring positive risks that could accelerate delivery or increase value.

PMP/SCRUM Example Question

During a release planning workshop, the Scrum Master facilitates risk identification. What is the most appropriate output of this activity?

1. A completed risk burndown chart with probability-impact scores.
2. An updated risk register with newly discovered risks and provisional owners.
3. A finalized mitigation plan with approved budget allocations.
4. A frozen product backlog to prevent scope changes.

Correct Answer: B — An updated risk register with newly discovered risks and provisional owners.

Explanation: Risk identification produces documented risks for further analysis and planning. Burndown charts, detailed response plans, and scope freezes are not direct outputs of identification.