methodatlas
Method guideArchitecture

Risk Storming

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityLow
Time60-90 min
Participants4-12
FormatWorkshop
MaturityEstablished
Plan Risk Storming
01

Prerequisite

What needs to be finished first

Complete firstComparable subject

Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.

Without a common frame, values are not comparable.
Complete firstEvidence access

Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log

Missing data remains visible as uncertainty.
02

Preparation

What needs to be ready before start

Materials

Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log

People / roles

Architecture/tech lead · developers · operations/security · domain/product · facilitator · risk owners

Pre-read

Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.

Time needed

90–150 minutes for one architecture view; action tracking separate.

Setup

Prepare a workspace with Context · Solo · Share · Assess · Treat · Review; separate example from live data.

03

Core question

The one question this method answers

Which concrete failure scenarios sit where in the architecture, which matter collectively, and how will we reduce or test them?

04

Flow

Phases with goal, actions, output and pitfall

The team places the architecture picture at the centre and gathers risks in a silent phase. The cards are then clustered, prioritised, and given owners or next steps. The review becomes a concrete action plan around the architecture.

Risk Storming · working structure

Fictional example

Fictional values show the actual method fields.

Risk Storming · working structure
RiskLocationScenarioQuality goalEvidenceExposureTreatmentOwner/review
R1 · Payment latencyAdd evidence and rationale.Payment API → checkout poolAPI slows → threads wait → pool exhausts → pickup failsAvailability; p80 waitLoad test: pool95%, errors 8%HighSeparate pool; GameDay ≤5%Noor · 15 Nov
R2 · Retry stormAdd evidence and rationale.Checkout → Payment APITimeout → unbounded retries → partner overloadResilience; partner limitRetry limit untestedMedium/unknownRetry budget and chaos testLea · 22 Nov

  1. 1. Location

    R1 · Payment latency
    Payment API → checkout pool
    R2 · Retry storm
    Checkout → Payment API

  2. 2. Scenario

    R1 · Payment latency
    API slows → threads wait → pool exhausts → pickup fails
    R2 · Retry storm
    Timeout → unbounded retries → partner overload

  3. 3. Quality goal

    R1 · Payment latency
    Availability; p80 wait
    R2 · Retry storm
    Resilience; partner limit

  4. 4. Evidence

    R1 · Payment latency
    Load test: pool95%, errors 8%
    R2 · Retry storm
    Retry limit untested

  5. 5. Exposure

    R1 · Payment latency
    High
    R2 · Retry storm
    Medium/unknown

  6. 6. Treatment

    R1 · Payment latency
    Separate pool; GameDay ≤5%
    R2 · Retry storm
    Retry budget and chaos test

  7. 7. Owner/review

    R1 · Payment latency
    Noor · 15 Nov
    R2 · Retry storm
    Lea · 22 Nov

All values are fictional.

Reference · original teaching example

  1. 1

    Context

    Shared map

    Goal

    Shared map: Read diagram, scope, quality goals, and assumptions together; resolve comprehension questions.

    Inputs for this step

    • Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.
    • Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log

    Actions

    • Read diagram, scope, quality goals, and assumptions together; resolve comprehension questions.

    Output

    Shared map

    Read diagram, scope, quality goals, and assumptions together; resolve comprehension questions.

    Quality check

    Does everyone understand elements, relationships, and critical quality goals alike?

    Pitfall

    Risks are collected on an outdated or unclear diagram. Mark version and model gaps before generating risks.

    Timing: 15–25 minutes

  2. 2

    Solo

    Risk stickies

    Goal

    Risk stickies: Each person silently identifies concrete risk scenarios and locates them on an element or relationship.

    Inputs for this step

    • Shared map

    Actions

    • Each person silently identifies concrete risk scenarios and locates them on an element or relationship.

    Output

    Risk stickies

    Each person silently identifies concrete risk scenarios and locates them on an element or relationship.

    Quality check

    Does every note contain trigger, event, and impact?

    Pitfall

    Stickies say only security or database. Write each as cause → event → effect.

    Timing: 15–25 minutes

  3. 3

    Share

    Risk clusters

    Goal

    Risk clusters: Explain notes in turn, cluster duplicates, and preserve different perspectives.

    Inputs for this step

    • Risk stickies

    Actions

    • Explain notes in turn, cluster duplicates, and preserve different perspectives.

    Output

    Risk clusters

    Explain notes in turn, cluster duplicates, and preserve different perspectives.

    Quality check

    Do distinct scenarios stay separate and common causes remain visible?

    Pitfall

    Majority opinion removes a rare expert perspective. Merge only identical trigger, path, and impact.

    Timing: 20–30 minutes

  4. 4

    Assess

    Priority view

    Goal

    Priority view: Justify qualitative exposure from plausible occurrence and consequence; mark evidence and unknowns.

    Inputs for this step

    • Risk clusters

    Actions

    • Justify qualitative exposure from plausible occurrence and consequence; mark evidence and unknowns.

    Output

    Priority view

    Justify qualitative exposure from plausible occurrence and consequence; mark evidence and unknowns.

    Quality check

    Is high exposure grounded in scenario and evidence rather than calculated points?

    Pitfall

    Invented 1–5 scores create false precision. Justify categories with evidence, uncertainty, and red lines.

    Timing: 15–25 minutes

  5. 5

    Treat

    Treatment plan

    Goal

    Treatment plan: For material risks avoid, reduce, transfer, or accept; assign experiment/ADR and owner.

    Inputs for this step

    • Priority view

    Actions

    • For material risks avoid, reduce, transfer, or accept; assign experiment/ADR and owner.

    Output

    Treatment plan

    For material risks avoid, reduce, transfer, or accept; assign experiment/ADR and owner.

    Quality check

    Does every action state expected risk effect and proof?

    Pitfall

    Add monitoring counts as a solution without signal and response. Specify control, measure, stop rule, and owner.

    Timing: 15–25 minutes

  6. 6

    Review

    Risk decision

    Goal

    Risk decision: Approve residual risk, update diagram/ADR, and set trigger for another risk storm.

    Inputs for this step

    • Treatment plan

    Actions

    • Approve residual risk, update diagram/ADR, and set trigger for another risk storm.

    Output

    Risk decision

    Approve residual risk, update diagram/ADR, and set trigger for another risk storm.

    Quality check

    Is acceptance owned by an authorised person with review date?

    Pitfall

    Risk list disappears after the workshop. Link register and revisit on architecture, load, or incident change.

    Timing: 10–20 minutes

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Risk Storming · Risiken am Artefakt findenArchitektur oder Plan sichtbar machen, Risiken still kleben, clustern und Top-Risiken mit Ownern in nächste Schritte überführen
Risk StormingDas Visual zeigt Risk Storming als annotiertes Architekturdiagramm mit stiller Klebphase, Risikokategorien, Clustern und Top-Risiken.Risiken direkt am Architektur- oder Planartefakt sichtbar machenStille Einzelarbeit verhindert Gruppendruck; Cluster und Doppelnennungen zeigen, welche Stellen besondere Aufmerksamkeit brauchen.Risikokategorientechnisch, organisatorisch, externStille Klebphasejede Person notiert Risiken ohneDiskussionArchitektur oder Plan als ArbeitsflächeClientAPIDatenPartnerAuth?RateSLAPIITeamCluster & DoppelnennungenMuster sichtbar machenTop-Risikenpriorisieren, Owner und nächste Aktionsetzenam Diagramm kleben, nicht danebenErstsammlungdann bewertenRisiken in ROAMüberführen
Form

Annotated architecture risk map with scenarios, affected elements/relationships, evidence, qualitative exposure, actions, owners, and review.

Versioning / ownership

Record date, team, data state, and review date; preserve prior versions.

Tool alternatives
  • Current architecture diagram
  • Perspective-coloured risk stickies
  • Risk and action register

risk-storming-working-template.md

Set subject, data, roles, flow, and review.

Risk Storming: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Complete run Time: 90–150 minutes for one architecture view; action tracking separate.

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log
  • Roles: Architecture/tech lead · developers · operations/security · domain/product · facilitator · risk owners
  • Advance information: Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.
  • Overall time needed: 90–150 minutes for one architecture view; action tracking separate.
  • Setup: Prepare a workspace with Context · Solo · Share · Assess · Treat · Review; separate example from live data.

Prepare for the work steps

Context: Shared map

  • Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.
  • Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log

Solo: Risk stickies

  • Shared map

Share: Risk clusters

  • Risk stickies

Assess: Priority view

  • Risk clusters

Treat: Treatment plan

  • Priority view

Review: Risk decision

  • Treatment plan

Risk Storming · working structure

RiskLocationScenarioQuality goalEvidenceExposureTreatmentOwner/review
R1 · Payment latency
R2 · Retry storm
  • R1 · Payment latency: Add evidence and rationale.
  • R2 · Retry storm: Add evidence and rationale.

The blank worksheet contains prompts only.

Reference · original teaching example

Context: Shared map

Expected artifact: Shared map

Read diagram, scope, quality goals, and assumptions together; resolve comprehension questions.

Entry:

...

  • Does everyone understand elements, relationships, and critical quality goals alike?

Solo: Risk stickies

Expected artifact: Risk stickies

Each person silently identifies concrete risk scenarios and locates them on an element or relationship.

Entry:

...

  • Does every note contain trigger, event, and impact?

Share: Risk clusters

Expected artifact: Risk clusters

Explain notes in turn, cluster duplicates, and preserve different perspectives.

Entry:

...

  • Do distinct scenarios stay separate and common causes remain visible?

Assess: Priority view

Expected artifact: Priority view

Justify qualitative exposure from plausible occurrence and consequence; mark evidence and unknowns.

Entry:

...

  • Is high exposure grounded in scenario and evidence rather than calculated points?

Treat: Treatment plan

Expected artifact: Treatment plan

For material risks avoid, reduce, transfer, or accept; assign experiment/ADR and owner.

Entry:

...

  • Does every action state expected risk effect and proof?

Review: Risk decision

Expected artifact: Risk decision

Approve residual risk, update diagram/ADR, and set trigger for another risk storm.

Entry:

...

  • Is acceptance owned by an authorised person with review date?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/risk-storming/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

risk-storming-beispiel.md

Concrete filled scenario, fictional example

Fictional teaching example: Risk Storming · working structure

RiskLocationScenarioQuality goalEvidenceExposureTreatmentOwner/review
R1 · Payment latencyPayment API → checkout poolAPI slows → threads wait → pool exhausts → pickup failsAvailability; p80 waitLoad test: pool95%, errors 8%HighSeparate pool; GameDay ≤5%Noor · 15 Nov
R2 · Retry stormCheckout → Payment APITimeout → unbounded retries → partner overloadResilience; partner limitRetry limit untestedMedium/unknownRetry budget and chaos testLea · 22 Nov
07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Shared mapRisks are collected on an outdated or unclear diagram.View in phase
  2. Risk stickiesStickies say only security or database.View in phase
  3. Risk clustersMajority opinion removes a rare expert perspective.View in phase
  4. Priority viewInvented 1–5 scores create false precision.View in phase
  5. Treatment planAdd monitoring counts as a solution without signal and response.View in phase
  6. Risk decisionRisk list disappears after the workshop.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

Stop Context: Does everyone understand elements, relationships, and critical quality goals alike?
Stop Solo: Does every note contain trigger, event, and impact?
Stop Share: Do distinct scenarios stay separate and common causes remain visible?
Stop Assess: Is high exposure grounded in scenario and evidence rather than calculated points?
Stop Treat: Does every action state expected risk effect and proof?
Stop Review: Is acceptance owned by an authorised person with review date?

Method after Agile Community. The method emerged from, or was spread through, the agile community of practice. Curated with 1 sources.

Sources: Risk Storming

Flow, timeboxes, and pitfalls are editorially curated practice recommendations based on the listed sources.

Where to go next?

Paper illustration of two considered options leading to a decision record with a marked status and visible consequences.
Architecture
Architecture Decision Record

Documents the accepted risk decision and diagram change as an architecture decision.

Paper illustration of RAID Log with a method-specific labelled workspace.
Delivery
RAID Log

Turns remaining risks and triggers into a running risk log.

View in playbookSafeguard Architecture Quality Before ImplementationMove from the guardrails of an architecture initiative through prioritized quality scenarios to a solution put up for review.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods