What needs to be finished first
An architecture diagram (for example C4 Container or Component level) or comparable visual map is available and understood by all participants.
What needs to be ready before start
Large-format print or digital board with architecture diagram at least A1 size; red, yellow, blue sticky notes for risk categories (technical, organizational, external); markers; timer; risk scoring grid (probability/impact).
One facilitator who protects silent phase and moderates clusters; 4-12 participants from mixed roles (architecture, engineering, operations, security, product); one scribe for owner assignment and actions.
Architecture diagram distributed 1-2 days beforehand with request to read; list of known incidents/problems from last 6 months; Quality Attributes (security, availability, scalability); risk category definition.
60-90 min
Diagram central on wall. Risk categories visible as legend (red=technical, yellow=organizational, blue=external). Announce silence rule. Evaluation grid (P/I 1-5) as banner.
The one question this method answers
Which risks are embedded in this architecture or plan artifact, and which of them need action before the next iteration?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Introduce context and categories | 10 min | Facilitator presents diagram (5 min), answers clarification questions. Explain risk categories and note colors. Give examples per category. | If understanding questions about diagram remain after 10 min, postpone workshop. Risk identification without architecture understanding is speculation. |
2Phase 2: Silent sticking phase | 20 min | Each participant notes risks on sticky notes (one note, one risk, color by category) and sticks them to the matching place in the diagram. No discussion. | Silence protects from anchoring effects. Anyone speaking gets one reminder. On repeated violation, short pause and reset. Silent phase is core protection of method. |
3Phase 3: Cluster and prioritize | 20-30 min | Together identify clusters and duplicates. Rate probability and impact (1-5) per cluster. Extract top risks from red area (P*I >=15). | Clusters are more important than individual mentions. If 5 participants independently name same risk, consensus is strong. Single mentions can still be valid, but examine more critically. |
4Phase 4: Owner and action | 15-20 min | Name owner per top risk, define next action (spike, mitigation, ROAM entry), set deadline. Maximum 5-7 top risks, rest into backlog. | Without owner, workshop fizzles. At least five risks with owner and deadline before end. Risk without action should be explicitly Accepted instead of forgotten. |
What comes out at the end
Annotated architecture diagram (photo or board export) plus risk list in markdown or table with category, description, P/I rating, owner, action, deadline. Linked with ROAM Board or RAID Log.
Snapshot per workshop with date, participant list and risk state. Repeat every 3-6 months as new entry, delta to previous version documented separately. Mark completed risks as Resolved, do not delete.
Compact working template for Risk Storming with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Diagram: C4 Container level Order Service v2.
Participants: 7 (Architecture, Backend, SRE, Security, Product, QA, DBA).
Top risks
Accepted risks: 3 further clusters marked as Accepted with rationale in ROAM Board.
Recognize symptoms and steer against them
Participants talk while sticking, dominant voices draw attention to their own risks.
Facilitator interrupts firmly at first violation, on repetition short pause and reset. Silence is core protection. Online: voting tool with hidden mode.
Notes say "we should add X" instead of "risk: without X, Y happens".
Clarify notation before Phase 2: risks as if-then or deficiency plus consequence. Solution ideas in separate parking lot. Solutions come after evaluation.
P/I values assigned without clear scale, consistency missing.
Define scale in writing before workshop (for example I=5: total outage >1h, I=3: degradation, I=1: cosmetic). Scale visible on wall.
Only engineers present, organizational and external risks missed.
Role check before workshop: architecture, backend, operations, security, product. If three roles missing, postpone or capture risks from missing perspective in follow-up.
Risks stick to diagram, nobody takes action, three months later workshop forgotten.
Enter owner and deadline per top risk into ROAM Board or RAID Log. Weekly risk review for 4 weeks after workshop. Risks without action either marked Accepted or re-evaluated.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.