MethodenanleitungDelivery

MoSCoW

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätNiedrig

Zeit30-90 min

Teilnehmende3-12

FormatWorkshop + Async

ReifegradCanonical

MoSCoW-Arbeit planen

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenFester Zeitraum

Release-Termin oder Timebox, Ziel und verfügbare Kapazität sind bekannt.

Ohne Zeitbezug kann jedes Item zum Must werden.

Vorher abschließenVergleichbare Items

Backlog-Items sind in ähnlicher Granularität beschrieben und haben mindestens grobe Aufwandssignale.

Uneinheitliche Ebenen machen Kategorien und Kapazitätsprüfung unbrauchbar.

Vorher abschließenEntscheidungsmandat

Eine Person oder Rolle kann den Release-Scope verbindlich festlegen.

Ohne Mandat bleiben Tauschentscheidungen offen.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Vier-Spalten-Board oder Backlog, Item-Beschreibungen, grobe Aufwände, Kapazitäts- und Abhängigkeitsinformationen sowie Timer.

Personen / Rollen

Product Owner oder verantwortliche Rolle entscheidet. Moderation hält den Must-Test und die Zeit. Delivery- und Fachperspektiven prüfen Aufwand, Risiken und Workarounds.

Vorabinfos

Release-Ziel, Termin, Kapazität, Risiken, Abhängigkeiten und bekannte Workarounds zusammentragen.

Zeitbedarf

30 bis 90 Minuten für eine erste Release-Sortierung. Detaillierte Schätzung und Refinement folgen separat.

Setup

Vier Spalten mit Must, Should, Could und Won’t Have this time anlegen. Kategorien und Änderungsregel vorab erklären.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Anforderungen müssen in diesem Release enthalten sein, welche sind verhandelbar und was bleibt bewusst für später?

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

MoSCoW ordnet Anforderungen nach Must, Should, Could und Won’t Have this time. Die Einstufung wird gegen Ziel, Abhängigkeiten, Risiken und verfügbare Kapazität geprüft.

MoSCoW-Board

Fiktives Werkzeugverleih-Pilotbeispiel

Zeitgebundene Release-Kategorien mit sichtbarem Spielraum.

Must Have

Fiktiv: Ausleihe erfassen

Ohne Nachweis keine sichere Rückgabe.

Should Have

Fiktiv: Erinnerungsnachricht

Wichtig, manueller Hinweis ist möglich.

Could Have

Fiktiv: Wunschliste

Nützlich, entfällt zuerst bei Zeitdruck.

Won’t Have this time

Fiktiv: Zweiter Abholort

Für diesen Pilotzeitraum bewusst verschoben.

Must-Test: Ohne Must-Item ist die Lieferung nicht sinnvoll, sicher oder zulässig.
Zeitbezug: Won’t gilt für diesen Zeitraum und ist später erneut verhandelbar.
Tauschregel: Bei Zeitdruck entfallen zuerst Coulds, danach Shoulds gemäß Entscheidung.

Agile Business Consortium / DSDM

1
Frame
Release und Must-Test klären
Ziel
Eine verbindliche Bewertungsbasis ist vereinbart.
Voraussetzungen für diesen Schritt
- Release-Ziel und Termin
- Kapazität, Constraints und Qualitätsgrenzen
Durchführung
- Zeitfenster und Lieferziel notieren
- Must-Test mit Beispielen vereinbaren
- Entscheidungsmandat und Abhängigkeiten klären
Ergebnis
Priorisierungsrahmen
Ohne Zeit- und Kapazitätsbezug verliert die Kategorie ihre Kraft.
Qualitätscheck
Won’t heißt ausdrücklich Won’t Have this time. Must beschreibt eine echte Liefergrenze, nicht bloß Wichtigkeit.
Stolperfalle
Alles Wichtige wird zum Must. Fragen, ob der Release ohne das Item nicht sinnvoll, sicher oder zulässig wäre.
Zeitlicher Rahmen: 10 Minuten
2
Classify
Items in vier Kategorien ordnen
Ziel
Jedes Item hat eine begründete Kategorie.
Voraussetzungen für diesen Schritt
- Backlog mit Items
- Abhängigkeiten, Risiken und Nutzen
Durchführung
- Items auf vergleichbare Granularität bringen
- Must, Should, Could oder Won’t Have this time vergeben
- Begründung und offene Uneinigkeit dokumentieren
Ergebnis
Kategorisiertes Backlog
Won’t beschreibt eine bewusste Verschiebung im aktuellen Zeitraum.
Qualitätscheck
Jedes Item ist genau einmal zugeordnet. Should hat keine tragfähige Begründung als Must.
Stolperfalle
Epics und Detailaufgaben werden direkt miteinander verglichen. Items auf eine gemeinsame Granularität bringen oder getrennte Ebenen planen.
Zeitlicher Rahmen: 20–30 Minuten
3
Constraints
Musts gegen Kapazität und Abhängigkeiten prüfen
Ziel
Ein realistischer Kernumfang ist sichtbar.
Voraussetzungen für diesen Schritt
- Kategorisiertes Backlog
- Kapazitäts- und Abhängigkeitsdaten
Durchführung
- Aufwand grob schätzen
- Must-Aufwand gegen Kapazität und harte Grenzen prüfen
- Abhängigkeiten und Risiken sichtbar machen
Ergebnis
Geprüfter Kernumfang
MoSCoW liefert keine falsche Präzision; grobe Größen reichen für die Grenze.
Qualitätscheck
Musts passen in die verfügbare Kapazität oder lösen eine bewusste Eskalation aus. Risiken und Abhängigkeiten haben Owner oder Entscheidung.
Stolperfalle
Die Must-Liste übersteigt die Kapazität deutlich. Kriterien und Scope neu verhandeln, bevor weitere Kategorien bewertet werden.
Zeitlicher Rahmen: 15–20 Minuten
4
Trade-offs
Shoulds und Coulds verhandeln
Ziel
Tauschentscheidungen und Fallback-Reihenfolge sind klar.
Voraussetzungen für diesen Schritt
- Geprüfter Must-Kern
- Should- und Could-Items
Durchführung
- Shoulds nach Wert, Schmerz und Workaround prüfen
- Coulds als bewusstes Flexibilitätspolster ordnen
- Reihenfolge für De-Scoping bei Zeitdruck vereinbaren
Ergebnis
Verhandelter Spielraum
Coulds sind kein zugesagter Umfang.
Qualitätscheck
Shoulds haben eine akzeptable Übergangslösung bei Verschiebung. Coulds können zuerst entfallen, ohne das Releaseziel zu brechen.
Stolperfalle
Coulds werden als stilles Versprechen behandelt. Als optional markieren und eine Streichreihenfolge vereinbaren.
Zeitlicher Rahmen: 15–20 Minuten
5
Commit
Release-Set und Won’t dokumentieren
Ziel
Scope, Verantwortlichkeit und Änderungsweg sind nachvollziehbar.
Voraussetzungen für diesen Schritt
- Verhandelte Kategorien
- Release- und Entscheidungsdaten
Durchführung
- Release-Set mit Ownern und Annahmen dokumentieren
- Won’t-Begründungen und möglichen späteren Zeitpunkt festhalten
- Review- und Änderungsregel vereinbaren
Ergebnis
Zeitgebundene Release-Entscheidung
Kategorien werden bei veränderten Constraints erneut bewertet.
Qualitätscheck
Won’t ist sichtbar und nicht als endgültige Ablehnung formuliert. Änderungen brauchen eine nachvollziehbare neue Entscheidung.
Stolperfalle
Die Liste wird nach dem Workshop still wieder geöffnet. Änderungsweg und Entscheidungskriterium sichtbar im Release-Dokument verankern.
Zeitlicher Rahmen: 10–15 Minuten

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

MoSCoW · Scope-PriorisierungMust, Should, Could und Won’t als verhandelbaren Lieferumfang mit Constraint-Prüfung trennen

Form

Datiertes, kategorisiertes Backlog mit Release-Scope, grobem Aufwand, Begründungen, Ownern und sichtbaren Trade-offs.

Versionierung / Ownership

Pro Release und Zeitraum eine Version führen. Kategorieänderungen mit Datum, Grund und neuer Entscheidung dokumentieren.

Tool-Alternativen

Backlog-Tool mit MoSCoW-Labels
Digitales Whiteboard mit vier Spalten
Tabelle mit Aufwand und Kapazität

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

moscow-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel: Werkzeugverleih-Pilot

Zeitraum: Vier Wochen, begrenztes Team und ein kleiner Werkzeugbestand.

Must: Ausleihe erfassen, Rückgabe dokumentieren und Sicherheitsregeln erklären. Should: Erinnerungsnachricht und einfache Auslastungsübersicht. Could: Wunschliste und automatische Empfehlungen. Won’t Have this time: Mehrere Abholorte, weil Personal und Prüfprozess im Zeitraum fehlen.

Die Kategorie Won’t bezieht sich auf diesen Pilotzeitraum. Nach dem Review kann sie neu bewertet werden; sie ist kein dauerhafter Ausschluss.

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

Release und Must-Test klärenAlles Wichtige wird zum Must.In der Phase ansehen
Items in vier Kategorien ordnenEpics und Detailaufgaben werden direkt miteinander verglichen.In der Phase ansehen
Musts gegen Kapazität und Abhängigkeiten prüfenDie Must-Liste übersteigt die Kapazität deutlich.In der Phase ansehen
Shoulds und Coulds verhandelnCoulds werden als stilles Versprechen behandelt.In der Phase ansehen
Release-Set und Won’t dokumentierenDie Liste wird nach dem Workshop still wieder geöffnet.In der Phase ansehen

Abbruchkriterien

Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest

Release-Ziel, Zeitraum oder Kapazität sind unbekannt.

Must-Test wurde nicht gemeinsam vereinbart.

Items haben stark unterschiedliche Granularität.

Musts sind ohne bewusste Entscheidung nicht lieferbar.

Entscheidungsmandat oder Änderungsweg fehlen.

Wie geht es weiter?

Decision Making

Trade-off Analysis

Dokumentiert die akzeptierten Kompromisse hinter den Won't-Items nachvollziehbar.

Papierboard mit den vier ROAM-Feldern Resolved, Owned, Accepted und Mitigated.

Agile

ROAM Board

Ordnet offene Risiken aus Trade-off-Notizen in Owned oder Mitigated ein.

Im Playbook ansehenPriorisierung und Roadmap klärenVon vielen Initiativen zu transparenter Reihenfolge, Scope und akzeptierten Trade-offs.

Methodenanleitung durchgearbeitet?

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

Zum Steckbrief Weitere Methoden