Was vorher fertig sein muss
Eine aktuelle Übersicht der relevanten Rollen und Stakeholder in der Organisation oder im Team liegt vor.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Matrix (Zeilen: Entscheidungstypen, Spalten: Rollen); RACI- oder RAPID-Notation als Banner; Liste der zu klärenden Entscheidungen; Org-Chart als Referenz; Tool für Vereinbarungs-Dokumentation.
Ein Facilitator (Coach, Org-Designer, HR-Partner); alle beteiligten Rollen-Inhaber oder ihre Vertreter; Sponsor mit Mandat zur Verbindlichkeit; Scribe für Vereinbarungen.
Liste wiederkehrender Entscheidungstypen (typisch 10-25); aktuelle Reibungen oder Eskalationen; bestehende implizite Regeln; Org-Chart und formale Verantwortlichkeiten.
90-180 min
Matrix vorbereiten: vertikal Entscheidungstypen (z. B. Hiring, Budget-Reallokation, Tech-Stack-Wahl, Release-Freigabe). Horizontal Rollen. Notation festlegen: D (Decide), R (Recommend), I (Input), F (Informed). Sponsor bestätigt Mandat.
Die eine Frage, die diese Methode beantwortet
Welche Rolle entscheidet welche Art von Entscheidung, welche Rollen werden vorher konsultiert, welche danach informiert, und wie binden wir das verbindlich?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Entscheidungstypen sammeln | 20-30 min | Pro Teilnehmer 3-5 wiederkehrende Entscheidungen mit Reibung benennen. Doppelte konsolidieren. Liste von 10-25 Typen, sortiert nach Häufigkeit oder Reibung. | Konkrete Entscheidungen, nicht abstrakte Kategorien. „Wer entscheidet über Sprint-Scope-Änderung mid-Sprint“ ist konkreter als „Scope-Entscheidungen“. |
2Phase 2: Rollen klären | 15 min | Rollen-Liste konsolidieren (PO, Tech Lead, Engineering Manager, Architect, CTO, etc.). Bei Doppelbelegungen klären, ob eine Rolle gemeint ist. | Person ungleich Rolle. Eine Person kann mehrere Rollen halten, aber Mapping geht auf Rolle. Bei Personenwechsel bleibt Vereinbarung gültig. |
3Phase 3: Pro Entscheidung Notation zuweisen | 30-60 min | Pro Entscheidungstyp Decide-Rolle bestimmen (genau eine), Recommend-Rollen, Input-Rollen, Informed-Rollen. Diskussion bei Doppelbelegungen oder Konflikten. | Genau ein Decider pro Entscheidung. Doppelte Decider sind Wurzel vieler Eskalationen. Konflikte aushandeln, nicht parken. |
4Phase 4: Konflikte und Sonderfälle | 20-30 min | Strittige Entscheidungen einzeln besprechen. Bei nicht-auflösbaren Konflikten Eskalations-Regel definieren (z. B. „bei Patt: Sponsor entscheidet binnen 48h“). | Pseudo-Konsens vermeiden. Lieber explizite Eskalations-Regel als Vereinbarung, die später jeder anders versteht. |
5Phase 5: Vereinbarung dokumentieren und kommunizieren | 10-15 min | Matrix als finales Artefakt. Alle Teilnehmer signieren (digital oder per E-Mail-Bestätigung). Kommunikation an breitere Org. Review-Termin in 3 Monaten setzen. | Ohne explizite Zustimmung pro Person verpufft Vereinbarung. Signieren ist symbolisch wichtig. Review-Cadence verhindert Drift. |
Was am Ende rauskommt
Decision-Rights-Matrix mit Entscheidungstypen, Rollen, Notation (D/R/I/F), Eskalationsregeln. Vereinbarung mit Datum, Teilnehmer, Sponsor-Bestätigung. Im Org-Wiki sichtbar abgelegt.
Vereinbarungs-Datum im Header. Änderungen mit neuem Datum und Begründung. Alte Versionen archivieren. Bei Org-Wechsel oder Sponsor-Wechsel re-konfirmieren.
Kompakte Arbeitsvorlage für Decision Rights Mapping mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Decision Rights Mapping Arbeitsmatrix
| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
## Ergebnisartefakte
- Decision-Rights-Matrix:
- Vereinbarung:
## Entscheidung oder Empfehlung
Welche Konsequenz ergibt sich aus der Matrix?Konkret gefülltes Szenario
## Decision Rights Mapping - Produkt-Team Discovery, 2026-05-18
**Sponsor**: @julia (CTO). **Teilnehmer**: PO @lisa, EM @marcus, Tech Lead @ben, Designer @anna, Architekt @michael.
**Matrix (Auszug)**
| Entscheidung | PO | EM | Tech Lead | Designer | Architekt | CTO |
|--------------|----|----|-----------|----------|-----------|-----|
| Sprint-Scope (Auswahl Stories) | D | I | R | R | F | F |
| Mid-Sprint Scope-Änderung | D | R | R | F | F | F |
| Tech-Stack-Wahl (neuer Service) | I | R | R | F | D | F |
| Library-Versions-Update (Major) | F | F | D | F | R | F |
| Hiring Engineer | R | D | R | F | F | F |
| Release-Freigabe Production | R | D | R | F | F | F |
| Compliance-relevante Architektur | F | F | R | F | R | D |
| Quartals-Budget | I | R | F | F | F | D |
**Eskalations-Regeln**
- Bei Patt zwischen PO und Tech Lead in Sprint-Scope: EM entscheidet binnen 24h.
- Bei Architektur-Konflikt mit Compliance-Implikation: CTO entscheidet binnen 48h nach formaler Eskalation.
- Bei Hiring-Patt: HR-Partner moderiert, CTO entscheidet final.
**Zustimmung**: Alle 6 Teilnehmer per E-Mail bestätigt am 18.05.2026.
**Review-Termin**: 18.08.2026 (3 Monate). Bei Personalwechsel oder Org-Änderung sofortiges Update.Symptome erkennen, gegensteuern
Bei mancher Entscheidung haben zwei Rollen „D“ in der Matrix, Eskalationen entstehen.
Genau ein Decider pro Entscheidung durchsetzen. Bei Streit aushandeln, wer Decider ist. Wenn keine Einigung, Eskalations-Regel an Sponsor.
Teilnehmer stimmen scheinbar zu, äußern aber später, dass sie etwas anderes verstanden hatten.
Pro Entscheidung Konsens laut formulieren und nachfragen. Explizite E-Mail- oder Schriftbestätigung. Wer nicht ausdrücklich zustimmt, lehnt ab.
Nach 6 Wochen entscheidet wieder jeder wie früher, Matrix hängt im Wiki ohne Wirkung.
Review-Cadence (3-6 Monate). Bei Reibung sofortige Eskalation an Matrix-Verweis. Onboarding neuer Mitglieder mit Matrix-Walkthrough.
„Strategische Entscheidungen“ als Typ - niemand weiß, welche konkrete Entscheidung gemeint ist.
Pro Typ konkretes Beispiel mitnotieren. Lieber 20 konkrete Typen als 5 vage. Bei Drift in Workshop konkretisieren.
Mapping geht auf Namen, bei Personalwechsel wird Vereinbarung ungültig.
Mapping auf Rollen. Person-Rolle-Zuordnung getrennt halten. Bei Personalwechsel nur Personen-Mapping aktualisieren, nicht ganze Matrix.
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.