Meine Session planen

# Session Brief: MoSCoW

## Ziel
Artefakt: Prioritized Backlog

## Arbeitsfrage
Welche Items müssen zwingend im Release sein, welche sind verhandelbar, und welcher Scope bleibt für die Verhandlung mit Stakeholdern?

## Kontext
Backlog mit Item-Beschreibungen; Effort-Schätzung pro Item (T-Shirt oder Story Points); bekannte Abhängigkeiten und Risiken; Constraints (Compliance, Verträge, externe Termine); Definition von „Must“ für diesen Release.

## Setup
- Format: Methoden-Session
- Dauer: 30-90 min
- Modus: Workshop oder async
- Teilnehmende: Ein Product Owner mit Mandat zur finalen Priorisierung; ein Facilitator (oft Scrum Master oder Delivery Lead); 2-5 Stakeholder, die Item-Verständnis und Business-Kontext einbringen; Team-Vertreter aus Engineering.
- Owner: Ein Product Owner mit Mandat zur finalen Priorisierung
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Prioritized Backlog hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Backlog-Tool (Linear, Jira, Notion) mit Status- oder Label-Feld für MoSCoW; Whiteboard oder digitales Board mit vier Spalten (Must, Should, Could, Won't this time); Timer.

## Vorbereitung
Vier Spalten als Board. Definition Must / Should / Could / Won't this time vorab erklären (Must = Release fällt sonst weg; Should = wichtig, Release ohne aber möglich; Could = wenn Zeit; Won't = bewusst nicht jetzt). Timer auf 60 min.

## Agenda
1. Sektion 1: Definition Must (10 min)
   Owner: Facilitator
   Aktion: Für diesen Release Must explizit definieren („ohne dieses Item ist Launch nicht möglich oder regulatorisch fehlerhaft“). Beispiele aus vergangenen Releases nennen. Hinweis: Wenn Must = „wichtig finde ich“ verhandelt wird, kollabiert die Methode. Schärfe in der Definition rettet den ganzen Workshop. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Prioritized Backlog

2. Sektion 2: Solo-Ranking durch PO (10-15 min)
   Owner: Facilitator
   Aktion: PO geht die Liste einmal durch und vergibt initiale Kategorie pro Item. Ohne Diskussion, nur Vorschlag. Andere notieren Abweichungen. Hinweis: PO-Ranking als Ausgangspunkt vermeidet endlose Gruppendiskussion. Andere bringen Korrekturen sichtbar mit, nicht im Vorbeigehen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Release Scope

3. Sektion 3: Diskussion und Konvergenz (20-40 min)
   Owner: Facilitator
   Aktion: Items mit Disagreement aufgreifen. Pro Item: Argument für Hochstufung, Argument für Herabstufung, Entscheidung durch PO. Kapazitätskontrolle: Musts müssen in <60% der Team-Kapazität passen. Hinweis: Wenn Musts >60% Kapazität, ist Release-Risiko hoch. Strikt prüfen: was kann zu Should werden, ohne dass Release platzt? Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Tradeoff Notes

4. Sektion 4: Won't this time klären (10 min)
   Owner: Facilitator
   Aktion: Items, die explizit raus sind, in Won't-Spalte. Mit Begründung dokumentieren. Klar machen: Won't = nicht jetzt, nicht „nie“. Hinweis: Won't this time explizit zu zeigen reduziert Stakeholder-Frust. Wenn ein Item nicht auftaucht, vermuten Stakeholder es sei vergessen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Prioritized Backlog

5. Sektion 5: Kapazitäts-Reality-Check (10 min)
   Owner: Owner
   Aktion: Geschätzten Effort der Musts und Shoulds gegen verfügbare Team-Kapazität rechnen. Wenn Musts allein schon >100% Kapazität, Release in Gefahr und Scope-Verhandlung nötig. Hinweis: Häufige Falle: Musts werden ohne Aufwandsrechnung gestapelt. Methode wirkt strukturiert, Release kollabiert trotzdem an Kapazität. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Release Scope

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Prioritized Backlog

## Abschluss
- Ergebnisartefakt aktualisieren: Prioritized Backlog
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Prioritized Backlog: MoSCoW

## Arbeitsfrage
Welche Items müssen zwingend im Release sein, welche sind verhandelbar, und welcher Scope bleibt für die Verhandlung mit Stakeholdern?

## Kontext
Backlog mit Item-Beschreibungen; Effort-Schätzung pro Item (T-Shirt oder Story Points); bekannte Abhängigkeiten und Risiken; Constraints (Compliance, Verträge, externe Termine); Definition von „Must“ für diesen Release.

## Beteiligte
- Owner: Ein Product Owner mit Mandat zur finalen Priorisierung
- Teilnehmende: Ein Product Owner mit Mandat zur finalen Priorisierung; ein Facilitator (oft Scrum Master oder Delivery Lead); 2-5 Stakeholder, die Item-Verständnis und Business-Kontext einbringen; Team-Vertreter aus Engineering.

## Input
Backlog-Tool (Linear, Jira, Notion) mit Status- oder Label-Feld für MoSCoW; Whiteboard oder digitales Board mit vier Spalten (Must, Should, Could, Won't this time); Timer.

## Vorlage
# MoSCoW Arbeitsvorlage

## Ziel

Priorisiert Scope in Must, Should, Could und Won't.

## 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
- Prioritized Backlog:
- Release Scope:
- Tradeoff Notes:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Prioritized Backlog ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren