methodatlas

Delivery Entscheidungsmethode

MoSCoW

Schneidet ein zeitgebundenes Release mit klaren Muss-, Spielraum- und Verschiebungsentscheidungen zu.

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.

Kernfrage
Welche Anforderungen müssen in diesem Release enthalten sein, welche sind verhandelbar und was bleibt bewusst für später?
Teilnehmende
3-12
Zeit
30-90 min

Die vier Kategorien beziehen sich auf diesen Zeitrahmen. Sie sind keine dauerhafte Rangliste und keine Punktesumme.

Papierillustration eines MoSCoW-Boards mit vier Spalten und sichtbarer Release-Grenze.
  1. Frame

    Release und Must-Test klären

    Lege Ziel, Zeitrahmen, Kapazität und die Bedeutung von Must für diesen Release fest.

  2. Classify

    Items in vier Kategorien ordnen

    Ordne vergleichbar geschnittene Items nach ihrer Bedeutung für diesen Release.

  3. Constraints

    Musts gegen Kapazität und Abhängigkeiten prüfen

    Prüfe, ob die Musts lieferbar sind und welche Reihenfolge oder Abhängigkeit den Release gefährdet.

  4. Trade-offs

    Shoulds und Coulds verhandeln

    Entscheide, welche wichtigen und wünschenswerten Items in den verbleibenden Spielraum passen.

  5. Commit

    Release-Set und Won’t dokumentieren

    Halte Musts, zugesagte Shoulds, optionale Coulds und Won’t Have this time als zeitgebundene Entscheidung fest.

MoSCoW gilt für einen konkreten Zeitraum. Bei neuem Termin, Kapazität oder Risiko die Kategorien neu prüfen; Won’t bedeutet nicht dauerhaft ausgeschlossen.

Geeignet, wenn

Du planst ein Release oder einen festen Arbeitsabschnitt und brauchst eine gemeinsam getragene Grenze für variablen Umfang.

Ideal für

  • Release Planning
  • Scope Control
  • Stakeholder Alignment

Nicht gut für

  • Feingranulares Ranking
  • Quantitative Portfolio-Scoring

Ergebnisse

  • MoSCoW-Backlog

    Jedes Item trägt eine begründete Kategorie für den aktuellen Zeitraum.

  • Release-Scope

    Must-Kern, Spielraum, Kapazität und Abhängigkeiten sind sichtbar.

  • Trade-off-Notizen

    Verschiebungen, Risiken und spätere Prüfzeitpunkte bleiben nachvollziehbar.

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

Erster Schritt

Benenne Release, Ziel, feste Zeit und verfügbare Kapazität. Vereinbare den Must-Test: Ohne dieses Item ist die Lieferung nicht sinnvoll, sicher oder zulässig.

Zur Methodenanleitung

Vertiefung

Zweck

Wenn ein Release zu viele Forderungen trägt und Prioritäten nur noch verhandelt werden, schafft MoSCoW klare Grenzen für den nächsten Zuschnitt. Must, Should, Could und Won’t machen Verbindlichkeit, Spielraum und Tauschlogik für alle Beteiligten sichtbar.

Funktionsweise

Die Einordnung trennt zwingende von verschiebbaren Punkten und spiegelt sie gegen Zeit, Risiko und Abhängigkeiten. Dadurch entsteht ein gemeinsames Gewichtungsbild, auf dem Zusagen, Kompromisse und eine belastbare Release-Grenze sauber aufbauen.

Im Detail

MoSCoW hilft, weil es Priorisierung in Verbindlichkeitsgrade übersetzt und damit den Zuschnitt eines Vorhabens hart sichtbar macht. Seine Wirkung entfaltet das Vorgehen, wenn jede Einstufung an Ziel, Risiko, Abhängigkeit und tatsächlicher Lieferbarkeit geprüft wird. Sauber bleibt die Priorisierung, wenn die Zahl der Must Punkte knapp bleibt, Grenzfälle offen verhandelt werden und die Kategorie Won't nicht still zurückkehrt, damit Scope nicht unkontrolliert wieder anwächst.

Durchführung

Lege vor dem Sortieren den betrachteten Release oder Planungshorizont fest und kläre, wer die Konsequenzen der Einstufung mitträgt. Meist kippt die Priorisierung dort, wo zu viele Punkte in Must rutschen; dann muss die Runde den Kern des Vorhabens neu schärfen. Schließe mit einer expliziten Release Grenze und sichtbaren Tauschentscheidungen für spätere Diskussionen.

Die Methodenanleitung führt mit 5 Phasen, Zeitrahmen, 5 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen
Artefakt-Vorlagen
MoSCoW: ArbeitsvorlageBereite eine zeitgebundene Release-Entscheidung mit sichtbaren Trade-offs vor.
markdown

moscow-working-template.md

Bereite eine zeitgebundene Release-Entscheidung mit sichtbaren Trade-offs vor.

MoSCoW: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Einen Release zuschneiden Zeit: 30 bis 90 Minuten für die erste Sortierung

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

  • Materialien: Vier-Spalten-Board oder Backlog, Item-Beschreibungen, grobe Aufwände, Kapazitäts- und Abhängigkeitsinformationen sowie Timer.
  • 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.
  • Vorab-Infos: Release-Ziel, Termin, Kapazität, Risiken, Abhängigkeiten und bekannte Workarounds zusammentragen.
  • Gesamter 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.

Für die Arbeitsschritte bereitstellen

Frame: Release und Must-Test klären

  • Release-Ziel und Termin
  • Kapazität, Constraints und Qualitätsgrenzen

Classify: Items in vier Kategorien ordnen

  • Backlog mit Items
  • Abhängigkeiten, Risiken und Nutzen

Constraints: Musts gegen Kapazität und Abhängigkeiten prüfen

  • Kategorisiertes Backlog
  • Kapazitäts- und Abhängigkeitsdaten

Trade-offs: Shoulds und Coulds verhandeln

  • Geprüfter Must-Kern
  • Should- und Could-Items

Commit: Release-Set und Won’t dokumentieren

  • Verhandelte Kategorien
  • Release- und Entscheidungsdaten

MoSCoW-Board

Must Have

...

Should Have

...

Could Have

...

Won’t Have this time

...

Arbeitsregeln

Must-Test ...

Zeitbezug ...

Tauschregel ...

Agile Business Consortium / DSDM

Frame: Release und Must-Test klären

Erwartetes Artefakt: Priorisierungsrahmen

Ohne Zeit- und Kapazitätsbezug verliert die Kategorie ihre Kraft.

Eintrag:

...

  • Won’t heißt ausdrücklich Won’t Have this time.
  • Must beschreibt eine echte Liefergrenze, nicht bloß Wichtigkeit.

Classify: Items in vier Kategorien ordnen

Erwartetes Artefakt: Kategorisiertes Backlog

Won’t beschreibt eine bewusste Verschiebung im aktuellen Zeitraum.

Eintrag:

...

  • Jedes Item ist genau einmal zugeordnet.
  • Should hat keine tragfähige Begründung als Must.

Constraints: Musts gegen Kapazität und Abhängigkeiten prüfen

Erwartetes Artefakt: Geprüfter Kernumfang

MoSCoW liefert keine falsche Präzision; grobe Größen reichen für die Grenze.

Eintrag:

...

  • Musts passen in die verfügbare Kapazität oder lösen eine bewusste Eskalation aus.
  • Risiken und Abhängigkeiten haben Owner oder Entscheidung.

Trade-offs: Shoulds und Coulds verhandeln

Erwartetes Artefakt: Verhandelter Spielraum

Coulds sind kein zugesagter Umfang.

Eintrag:

...

  • Shoulds haben eine akzeptable Übergangslösung bei Verschiebung.
  • Coulds können zuerst entfallen, ohne das Releaseziel zu brechen.

Commit: Release-Set und Won’t dokumentieren

Erwartetes Artefakt: Zeitgebundene Release-Entscheidung

Kategorien werden bei veränderten Constraints erneut bewertet.

Eintrag:

...

  • Won’t ist sichtbar und nicht als endgültige Ablehnung formuliert.
  • Änderungen brauchen eine nachvollziehbare neue Entscheidung.

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/moscow/run-sheet

Alternativen und Nachbarn

Passende Alternativen mit Entscheidungshilfe, danach weitere verwandte Methoden.

Alle Methoden
Rahmenbedingungen und Herkunft
NiedrigWorkshop + Async30-90 min

Steckbrief

Methodenform
Entscheidungsmethode
Teilnehmende
3-12
Zeit
30-90 min
Reifegrad
Canonical
Ursprung
Dai Clegg
Papierillustration zu Trade-off Analysis.
Als Nächstes: Trade-off Analysis