Was vorher fertig sein muss
Ein Architekturdiagramm (z. B. C4 Container- oder Component-Ebene) oder eine vergleichbare visuelle Karte liegt vor und ist allen Teilnehmern verständlich.
Was vor Start vorliegen muss
Großformatiger Druck oder digitales Board mit Architekturdiagramm in mindestens A1-Größe; rote, gelbe, blaue Haftnotizen für Risikokategorien (technisch, organisatorisch, extern); Marker; Timer; Risiko-Bewertungsraster (Wahrscheinlichkeit/Auswirkung).
Ein Facilitator, der stille Phase schützt und Cluster moderiert; 4-12 Teilnehmer aus gemischten Rollen (Architektur, Engineering, Operations, Security, Product); ein Scribe für Owner-Zuweisung und Aktionen.
Architekturdiagramm 1-2 Tage vorher verteilt mit Aufforderung zum Vorlesen; Liste bekannter Vorfälle/Probleme der letzten 6 Monate; Quality Attributes (Sicherheit, Verfügbarkeit, Skalierung); Risiko-Kategorien-Definition.
60-90 min
Diagramm zentral an Wand. Risikokategorien als Legende sichtbar (rot=technisch, gelb=organisatorisch, blau=extern). Stille-Regel ankündigen. Bewertungsraster (W/A 1-5) als Banner.
Die eine Frage, die diese Methode beantwortet
Welche Risiken stecken in diesem Architektur- oder Plan-Artefakt, und welche davon brauchen Aktion vor der nächsten Iteration?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Kontext und Kategorien einführen | 10 min | Facilitator stellt Diagramm vor (5 min), beantwortet Klärungsfragen. Risikokategorien und Notizfarben erklären. Beispiele pro Kategorie geben. | Wenn nach 10 min noch Verständnisfragen zum Diagramm offen sind, Workshop vertagen. Risiko-Identifikation ohne Architektur-Verständnis ist Spekulation. |
2Phase 2: Stille Klebphase | 20 min | Jeder Teilnehmer notiert Risiken auf Haftnotizen (eine Notiz, ein Risiko, Farbe nach Kategorie) und klebt sie an die passende Stelle des Diagramms. Keine Diskussion. | Stille schützt vor Anker-Effekten. Wer redet, wird einmal erinnert. Bei wiederholtem Verstoß kurze Pause und Reset. Stille-Phase ist Kernschutz der Methode. |
3Phase 3: Cluster bilden und priorisieren | 20-30 min | Gemeinsam Cluster und Doppelnennungen identifizieren. Pro Cluster Wahrscheinlichkeit und Auswirkung (1-5) bewerten. Top-Risiken aus rotem Bereich (W*A >=15) extrahieren. | Cluster sind wichtiger als Einzelnennungen. Wenn 5 Teilnehmer dasselbe Risiko unabhängig nennen, ist Konsens stark. Einzel-Nennungen können trotzdem valide sein, aber kritischer prüfen. |
4Phase 4: Owner und Aktion | 15-20 min | Pro Top-Risiko Owner benennen, nächste Aktion definieren (Spike, Mitigation, ROAM-Eintrag), Frist setzen. Maximal 5-7 Top-Risiken, Rest in Backlog. | Ohne Owner verpufft der Workshop. Mindestens fünf Risiken mit Owner und Frist vor Ende. Risiko ohne Aktion sollte explizit „Accepted“ statt „vergessen“ sein. |
Was am Ende rauskommt
Annotiertes Architekturdiagramm (Foto oder Board-Export) plus Risikoliste in Markdown oder Tabelle mit Kategorie, Beschreibung, W/A-Bewertung, Owner, Aktion, Frist. Verlinkt mit ROAM-Board oder RAID-Log.
Pro Workshop Snapshot mit Datum, Teilnehmer-Liste und Risiko-Stand. Wiederholungen alle 3-6 Monate als neuer Eintrag, Delta zur Vorversion separat dokumentiert. Erledigte Risiken als „Resolved“ markieren, nicht löschen.
Kompakte Arbeitsvorlage für Risk Storming mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Risk Storming Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Annotiertes Diagramm:
- Risikoliste mit Priorisierung:
- Maßnahmen-Backlog:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Risk Storming - Order-Service-Architektur, 2026-05-18
**Diagramm**: C4 Container-Ebene Order-Service v2.
**Teilnehmer**: 7 (Architektur, Backend, SRE, Security, Product, QA, DBA).
**Top-Risiken**
1. **Tech-rot, W4/A5**: Datenbank-Replikation single-leader, kein automatischer Failover. Cluster mit 4 Nennungen. Owner: @ben, Spike „Multi-Leader-Setup“ bis 30.05.
2. **Tech-rot, W3/A5**: Payment-Webhook ohne Retry-Mechanismus bei 5xx-Fehlern. Cluster mit 3 Nennungen. Owner: @anna, Mitigation in Sprint 23.
3. **Org-gelb, W4/A4**: Order-Service-Wissen konzentriert auf einen Engineer. Owner: @lisa, Knowledge-Sharing-Plan bis 15.06.
4. **Extern-blau, W3/A4**: PSP-Provider plant Breaking Change im Q3, keine Test-Sandbox verfügbar. Owner: @marcus, Eskalation an PSP-Account-Manager.
5. **Tech-rot, W3/A4**: Inventory-Service hat keine Idempotenz auf Stock-Reservation-Calls. Owner: @ben, Refactor in Sprint 24.
**Akzeptierte Risiken**: 3 weitere Cluster als „Accepted“ markiert mit Begründung im ROAM-Board.Symptome erkennen, gegensteuern
Teilnehmer reden bereits beim Kleben, dominante Stimmen lenken Aufmerksamkeit auf eigene Risiken.
Facilitator unterbricht hart bei erstem Verstoß, bei Wiederholung kurze Pause und Reset. Stille ist Kernschutz. Online: Voting-Tool mit verdecktem Modus.
Notizen lauten „wir sollten X einbauen“ statt „Risiko: ohne X passiert Y“.
Vor Phase 2 Notation klären: Risiken als „Wenn-dann“ oder „Mangel + Konsequenz“. Lösungsideen in separaten Parkplatz. Lösungen kommen nach Bewertung.
W/A-Werte werden ohne klare Skala vergeben, Konsistenz fehlt.
Skala vor Workshop schriftlich definieren (z. B. „A=5: Komplettausfall >1h, A=3: Degradation, A=1: Kosmetisch“). Skala an Wand sichtbar.
Nur Engineers anwesend, organisatorische und externe Risiken werden übersehen.
Vor Workshop Rollen-Check: Architektur, Backend, Operations, Security, Product. Wenn drei Rollen fehlen, Workshop verschieben oder Risiken aus fehlender Perspektive in Followup.
Risiken kleben am Diagramm, niemand übernimmt Aktion, drei Monate später ist Workshop vergessen.
Pro Top-Risiko Owner und Frist im ROAM-Board oder RAID-Log eintragen. Wöchentliches Risiko-Review für 4 Wochen nach Workshop. Risiken ohne Aktion entweder als „Accepted“ markieren oder erneut bewerten.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.