Was ist die Priorisierungsmethode Must Should Could Won't?
Must Should Could Won't, besser bekannt als MoSCoW, teilt Arbeit in vier Gruppen ein: was ihr tun müsst, was ihr tun solltet, was ihr tun könntet, wenn Zeit bleibt, und was ihr diesmal nicht tut. Als Retrospektive bringt die Methode euer Team dazu, sich offen und gemeinsam auf die Prioritäten für den nächsten Sprint oder das nächste Release zu einigen. Dai Clegg hat die Methode in den 1990er-Jahren bei Oracle entwickelt. Seitdem gehört sie fest zum agilen Projektmanagement und zur Business-Analyse, vor allem im DSDM. Die Kategorien lauten Must have (kritisch), Should have (wichtig), Could have (wünschenswert) und Won't have (diesmal nicht). Die Methode passt gut zu agilem Arbeiten, weil sie die Arbeit mit dem höchsten Wert an die erste Stelle setzt. Außerdem bietet sie dem Product Owner eine strukturierte Möglichkeit, das Backlog aus Sicht der Kunden zu betrachten: Würde ein Kunde etwas beim Launch vermissen, ist es wahrscheinlich ein Must. Die Won't-Spalte leistet mehr, als man ihr ansieht. Wenn ihr festhaltet, worauf ihr bewusst verzichtet, schleicht es sich nicht wieder in den Sprint ein, und die Stakeholder sehen klar, was nicht geliefert wird.
Must-Should-Could-Won't-Format
Must
Was müssen wir auf jeden Fall liefern?
Hier geht es um nicht verhandelbare Anforderungen, die für den Erfolg entscheidend sind. Ermutigt die Teilnehmenden bei den Must-Einträgen, an echte Blocker oder unverzichtbare Elemente zu denken, ohne die das Projekt scheitern würde. Fordert das Team auf, streng zu prüfen, was wirklich als Must gilt, damit nicht am Ende alles höchste Priorität hat.
Should
Was ist wichtig, aber nicht kritisch?
Das sind wichtige Funktionen oder Anforderungen, die deutlichen Mehrwert bringen, aber für den Launch nicht entscheidend sind. Lenkt das Team auf Einträge, deren Fehlen wehtun würde, ohne dass das Projekt deshalb nicht funktioniert. Konzentriert euch auf Dinge mit hohem Wert, aber geringerer Dringlichkeit.
Could
Was wäre schön, wenn die Zeit reicht?
Das sind wünschenswerte Funktionen, die man gern hätte, wenn die Ressourcen es zulassen. Helft dem Team, Verbesserungen zu finden, die die Lösung besser machen, aber nicht unbedingt nötig sind. Solche Einträge eignen sich oft gut für spätere Iterationen oder Releases.
Won't
Worauf verzichten wir diesmal bewusst?
Das sind Punkte, gegen die sich das Team für diese Iteration oder dieses Projekt ausdrücklich entscheidet. Ermutigt zu einer ehrlichen Diskussion über Funktionen, die sich vielleicht lohnen würden, aber nicht zu den aktuellen Zielen oder Rahmenbedingungen passen. Wenn ihr sie klar benennt, bleibt das Team fokussiert und alle wissen, woran sie sind.
Wann sollte diese Retrospektive durchgeführt werden?
- Wenn ihr ein neues Projekt oder eine neue Initiative plant und klare Prioritäten braucht
- Beim Backlog Refinement, um Feature-Anfragen zu sortieren und zu priorisieren
- Wenn die Ressourcen knapp sind und ihr harte Entscheidungen zum Umfang treffen müsst
- In Meetings mit Stakeholdern, um Erwartungen daran zu klären, was wann geliefert wird
Vorschläge für Fragen zum Icebreaker
- Was war die schwierigste Priorisierungsentscheidung, die du in einem Projekt treffen musstest?
- Wenn du in deinem aktuellen Projekt nur drei Funktionen liefern könntest, welche wären das und warum?
Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →
Ideen und Tipps für Ihre Retrospektive
- Haltet die Must-Einträge bei höchstens etwa 60 % des Gesamtaufwands, wie es DSDM empfiehlt, damit der Plan Puffer für Überraschungen hat
- Überprüft die Kategorien erneut, wenn sich geschäftliche Anforderungen und Rahmenbedingungen ändern
- Begrenzt die Diskussion pro Eintrag zeitlich, damit nicht eine einzige Debatte das ganze Meeting auffrisst
- Haltet fest, warum ein Eintrag in seiner Kategorie gelandet ist, damit die nächste Diskussion nicht wieder bei null beginnt
- Bezieht die Stakeholder ein, denen die Anforderungen gehören, damit die Prioritäten Bestand haben
- Prüft Abhängigkeiten, bevor ihr einen Eintrag einordnet: Ein Could, von dem ein Must abhängt, ist in Wirklichkeit ein Must
Häufig gestellte Fragen
Was ist die MoSCoW-Methode?
Was bedeuten Must, Should, Could und Won't?
Wie führt man eine MoSCoW-Retrospektive durch?
Warum heißt die Methode MoSCoW?
Wie viele Einträge sollten Musts sein?
Verwandte Vorlagen
Sammle umsetzbares Feedback zu deinem Sprint Review.
Rose-Bud-Thorn-Retrospektive
Benennt Erfolge, erste Chancen und Schmerzpunkte eures Teams in einer Session.
What? So What? Now What?-Retrospektive
Von dem, was passiert ist, zu dem, was ihr als Nächstes tut.
FLAP-Retrospektive
Erkenntnisse, Erfolge und Probleme reflektieren und dann die nächsten Schritte planen