Run SheetFacilitationDecision Workshop

Decision Jam

KomplexitätLow

Zeit60-90 min

Teilnehmende4-10

FormatWorkshop

MaturityEstablished

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro mit Bereichen für Problem-Sammlung, Voting, HMW-Reframe, Lösungsideen und Entscheidung; Stickies; Timer; Aktionsliste; geteilter Pre-Read.

Personen / Rollen

Ein Facilitator; 4-10 Teilnehmende; ein Entscheider (oft im Team selbst, z. B. PM oder Team Lead); ein Scribe.

Vorabinfos

Kontext: was beschäftigt das Team aktuell; bekannte Spannungen; Zeit-Druck oder Anlass; Hinweis, dass Format auf schnelle Konvergenz zielt.

Zeitbedarf

60-90 min

Setup

Bereiche an die Wand. Regel: jede Phase strikt timeboxed, kein Vorgriff. Entscheidungsbefugnis vorab klären.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welches Problem ist heute am wichtigsten, und welcher konkrete erste Schritt verändert es in den nächsten 14 Tagen?

Ablauf

Marker: Minute

Schritt	Dauer	Aktion	Hinweis
10-10 min	10 min	Stillarbeit: Probleme oder Frustrationspunkte still auf Stickies, max 5 pro Person. Kurze Formulierung.	Stillarbeit verhindert Dominanz. Wer sofort redet, beeinflusst andere. Keine Diskussion in dieser Phase.
210-20 min	10 min	Reihum vorstellen, clustern, Voting (3 Dots pro Person). Top-Problem identifizieren.	Voting stillschweigend und gleichzeitig. Top-Problem wird Fokus der Restzeit. Klare Entscheidung, nicht Konsens-Suche.
320-30 min	10 min	Top-Problem reframen als „How might we...“-Frage. Mehrere HMW-Varianten generieren, dann eine wählen.	HMW ist Methodenkern. „Wie könnten wir X reduzieren, damit Y eintritt?“. Wer zu eng reframed, killt Lösungsraum.
430-50 min	20 min	Stillarbeit Lösungsideen zur HMW: Crazy 8s oder Brainwriting, mind. 5 pro Person. Anschließend reihum vorstellen.	Quantität vor Qualität. Wer nach 5 min aufhört, hat nicht durchgedacht. Auch absurde Ideen schreiben, kurbeln Kreativität an.
550-70 min	20 min	Voting (3 Dots pro Person). Top-Lösung wählen. Diskussion: was wäre der kleinste Experiment-Schritt in 14 Tagen?	Experiment statt Programm. Nicht „wir lösen X“, sondern „wir testen Y und lernen“.
670-90 min	20 min	Experiment ausformulieren: was, wer, bis wann, woran erkennen wir Erfolg/Misserfolg. Maximal 2-3 Experimente.	Owner anwesend und stimmt zu. Erfolgskriterium muss in 14 Tagen messbar oder beobachtbar sein.

Artefakt

Was am Ende rauskommt

Form

Workshop-Eintrag mit Datum, Teilnehmenden, identifiziertem Top-Problem, HMW-Reframe, Top-Lösungen, gewähltem Experiment mit Owner, Datum und Erfolgskriterium sowie Follow-up-Termin.

Tool-Alternativen

Miro mit Decision-Jam-Template
FigJam mit Spalten
Whiteboard mit Foto-Export
Notion-Page mit Sektionen

Versionierung / Ownership

Pro Decision Jam ein Eintrag. Bei mehreren Jams zum gleichen Thema verlinken, Experiment-Ergebnisse einarbeiten.

markdown

Decision Jam Arbeitsvorlage

Kompakte Arbeitsvorlage für Decision Jam mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Decision Jam Arbeitsvorlage

## Ziel

Kurzer Workshop, um Probleme zu priorisieren und in konkrete Experimente zu übersetzen.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Problem Cluster:
- Prioritized Challenge:
- Experiment:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

decision-jam-beispiel.md

markdown

## Decision Jam — Team Backend, „Was bremst uns gerade am stärksten?“ (24.05.2026, 75 min, 6 Engineers)

**Top-Probleme (gevotet)**:
1. PR-Review-Zeiten 1-3 Tage (12 Dots)
2. Unklare Definition of Done (8 Dots)
3. Datenbank-Migration-Schmerzen (5 Dots)

**Top-Problem gewählt**: PR-Review-Zeiten.

**HMW**: Wie könnten wir PR-Reviews innerhalb von 4 Arbeitsstunden abschließen, ohne die Qualität zu opfern?

**Lösungsideen (Auszug)**:
- Review-Pflicht für 1 PR pro Tag pro Engineer
- Pair-Review als Standard für komplexe PRs
- Code-Review-Slot vormittags 11:00-12:00 fix
- Smaller PRs (max. 300 LOC) erzwingen
- Bot-Reminder nach 4 h
- Async-Review-Template mit Checkliste

**Top-Lösung (Voting)**: Code-Review-Slot 11:00-12:00 fix + Bot-Reminder nach 4 h.

**Experiment (2 Wochen ab 27.05.)**:
1. Tägliches 11:00-12:00 Review-Slot, jeder schließt Reviews. Owner: @anna (Engineering Lead). Erfolg: 80% der PRs <4 h offen.
2. Slack-Bot, der bei PR >4 h offen ping macht. Owner: @ben, bis 27.05. konfiguriert.

**Review**: 10.06.2026 in nächster Retro.

Was tun

Nur Owner im Raum bekommen Aktionen. Wenn jemand fehlt, alternative Person oder Verschiebung.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Probleme sind strategisch und brauchen Tiefe, Decision Jam zu oberflächlich; Consensus Workshop oder RAPID passender.

Gruppe ist über 10, Format wird unmoderierbar.

Sicherheit fehlt, Problem-Sammelphase wird gefiltert.

Entscheidungsbefugnis ist nicht im Raum, Experiment-Owner kann nicht zusagen.

Zeit reicht nicht (unter 60 min), Phasen werden gehetzt.

Top-Problem ist außerhalb des Team-Mandats, Experiment ist nicht durchführbar.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden