Was vorher fertig sein muss
Ein verbindlicher Liefertermin oder Release-Window steht fest, sodass die MoSCoW-Verhandlung Constraint-getrieben statt wunsch-getrieben ist.
Eine Liste an Items, Stories oder Features in vergleichbarer Granularität liegt vor (idealerweise INVEST-konforme Stories).
Was vor Start vorliegen muss
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.
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.
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.
30-90 min
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.
Die eine Frage, die diese Methode beantwortet
Welche Items müssen zwingend im Release sein, welche sind verhandelbar, und welcher Scope bleibt für die Verhandlung mit Stakeholdern?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Definition Must | 10 min | Für diesen Release Must explizit definieren („ohne dieses Item ist Launch nicht möglich oder regulatorisch fehlerhaft“). Beispiele aus vergangenen Releases nennen. | Wenn Must = „wichtig finde ich“ verhandelt wird, kollabiert die Methode. Schärfe in der Definition rettet den ganzen Workshop. |
2Sektion 2: Solo-Ranking durch PO | 10-15 min | PO geht die Liste einmal durch und vergibt initiale Kategorie pro Item. Ohne Diskussion, nur Vorschlag. Andere notieren Abweichungen. | PO-Ranking als Ausgangspunkt vermeidet endlose Gruppendiskussion. Andere bringen Korrekturen sichtbar mit, nicht im Vorbeigehen. |
3Sektion 3: Diskussion und Konvergenz | 20-40 min | 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. | Wenn Musts >60% Kapazität, ist Release-Risiko hoch. Strikt prüfen: was kann zu Should werden, ohne dass Release platzt? |
4Sektion 4: Won't this time klären | 10 min | Items, die explizit raus sind, in Won't-Spalte. Mit Begründung dokumentieren. Klar machen: Won't = nicht jetzt, nicht „nie“. | Won't this time explizit zu zeigen reduziert Stakeholder-Frust. Wenn ein Item nicht auftaucht, vermuten Stakeholder es sei vergessen. |
5Sektion 5: Kapazitäts-Reality-Check | 10 min | 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. | Häufige Falle: Musts werden ohne Aufwandsrechnung gestapelt. Methode wirkt strukturiert, Release kollabiert trotzdem an Kapazität. |
Was am Ende rauskommt
Priorisiertes Backlog (in Linear, Jira, Notion oder Tabelle) mit MoSCoW-Label pro Item, plus Release-Scope-Dokument mit Liste der Musts mit Effort-Summe, Shoulds als Stretch, Coulds als Optional und Won't this time mit Begründung.
Pro Release-Runde eigene Version mit Datum und Release-Name. Verschiebungen zwischen Kategorien während des Sprints dokumentieren (z. B. „Item X von Should zu Must verschoben am 12.06., Grund: Compliance-Update“).
Kompakte Arbeitsvorlage für MoSCoW mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 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.Konkret gefülltes Szenario
## MoSCoW — Release v3.4 „Checkout v2“ (geplant 2026-07-15)
**Team-Kapazität**: 4 Devs × 6 Wochen = ~96 Personentage netto.
### Must (zusammen 52 PT, 54% Kapazität)
- Stripe-3DS2-Compliance-Update (12 PT) — regulatorisch zwingend bis 30.06.
- Checkout-Flow Refactoring (20 PT) — Voraussetzung für 3DS2
- Migrations-Skript für offene Orders (8 PT)
- Smoke-Test-Suite für neuen Flow (12 PT)
### Should (zusammen 28 PT)
- Apple-Pay-Integration (16 PT) — Marketing-Push abhängig, aber Release ohne möglich
- Bessere Fehlertexte (8 PT) — User-Wunsch aus Interviews
- Saved-Card-Option (4 PT)
### Could (zusammen 14 PT)
- One-Click-Reorder (10 PT)
- A/B-Test-Framework im Checkout (4 PT)
### Won't this time
- Buy-Now-Pay-Later-Integration — abhängig von Vertragsverhandlung mit Klarna, frühestens Q4
- Multi-Currency-Support — kein Customer-Demand bestätigt, parken
**Status**: Musts 54% Kapazität, Puffer für Shoulds und Unvorhergesehenes da. Apple-Pay als wahrscheinlicher Stretch.Symptome erkennen, gegensteuern
70-90% der Items landen in Must, Should und Could sind fast leer.
Must-Definition strikt anwenden: „Release fällt aus, wenn Item fehlt“. Wer „wichtig“ sagt, meint Should. PO setzt im Zweifel Should.
Items werden priorisiert ohne Größenangabe, Kapazitäts-Rechnung fehlt.
T-Shirt-Sizing oder Story Points pro Item, mindestens grob. Ohne Größe ist Priorisierung wertlos für Kapazitäts-Entscheidung.
Won't-Items werden gestrichen, ohne dass Stakeholder verstehen, ob sie verloren sind.
Won't this time explizit benennen. Klare Aussage: jetzt nicht, mögliche Aufnahme in nächstem Release. Sonst Eskalation und Vertrauensverlust.
Nach dem Workshop bleibt die Liste „vorläufig“, jeder verhandelt im Backchannel weiter.
PO unterschreibt am Ende. Änderungen nur über Change-Request mit Begründung. Sonst entwertet sich die Methode in Wochenfrist.
Epics und Detail-Stories landen in derselben Bewertungs-Liste.
Vor MoSCoW-Workshop Items auf vergleichbares Niveau bringen. Epics in Stories splitten oder Stories zu Epics aggregieren. Sonst werden Ratings unbrauchbar.
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.