MoSCoW-Priorisierung: Anforderungen richtig einteilen

Wenn in einem Workshop alle Anforderungen auf der Wand kleben und jemand fragt, was davon wichtig ist, passiert immer dasselbe: Fast alles wird zum Muss erklärt. Das ist menschlich. Wer zugibt, dass sein Wunsch verschiebbar ist, fürchtet, ihn nie umgesetzt zu sehen.

MoSCoW löst dieses Problem nicht mit Psychologie, sondern mit Mathematik. Die Methode geht auf Dai Clegg zurück, der sie 1994 für Projekte mit Rapid Application Development entwickelte. Breit bekannt wurde sie über das DSDM-Framework. Heute pflegt das Agile Business Consortium die zugehörigen Empfehlungen, und deren Kern ist eine Zahl: Muss-Anforderungen sollen höchstens 60 Prozent des geschätzten Aufwands ausmachen.

Die vier Kategorien, genau genommen

Die Definitionen klingen banal. In der Anwendung entscheidet die Präzision.

Das „this time“ in der letzten Zeile ist wichtiger, als es aussieht. Es nimmt dem Gespräch die Schärfe, weil kein Wunsch endgültig verschwindet. Die beiden kleinen o im Namen sind übrigens nur Füllbuchstaben.

Testfragen für ein echtes Muss

Bevor eine Anforderung als Muss durchgeht, sollte sie diese Fragen überstehen:

• Können wir live gehen, wenn genau diese Funktion fehlt?
• Gibt es einen Umweg, auch einen umständlichen, manuellen?
• Verstoßen wir ohne sie gegen ein Gesetz, einen Vertrag oder eine Sicherheitsvorgabe?
• Würde die wichtigste Nutzergruppe die Software ohne sie ablehnen?

Wenn die Antwort auf die ersten beiden Fragen „ja“ lautet, ist es kein Muss. Ein typisches Beispiel ist der PDF-Export von Berichten. Fast jeder will ihn. Für den Start reicht aber oft der Browser-Druck in eine PDF-Datei, und der Export wandert ins Soll.

Die 60-Prozent-Regel mit Rechenbeispiel

Warum 60 Prozent? Weil Schätzungen in frühen Projektphasen unsicher sind. Steve McConnell beschreibt im Kegel der Unsicherheit, dass selbst nach abgeschlossener Anforderungsklärung noch Abweichungen von minus einem Drittel bis plus 50 Prozent realistisch sind. Wer 100 Prozent des Budgets mit Muss-Anforderungen füllt, hat keine Reserve. Jede Verzögerung gefährdet dann den Kern.

Die Empfehlung arbeitet mit Aufwand, nicht mit der Anzahl der Anforderungen. Zehn kleine Muss-Punkte können weniger kosten als ein großer.

• Must have60 %
• Should have20 %
• Could have20 %

Muss höchstens 60 % und Kann um 20 % laut Agile Business Consortium. Der Soll-Anteil ergibt sich als Rest und ist eine Orientierung, keine feste Vorgabe.

So sieht das an einem konkreten Projekt aus. Angenommen, das Team schätzt alle Anforderungen für ein Kundenportal auf 420 Personentage. Das Budget gibt 400 Personentage her.

Budget

400 PT

Obergrenze Must (60 %)

240 PT

Geschätzte Must-Anforderungen

275 PT

Überhang, der heruntergestuft werden muss

35 PT

Should und Could zusammen maximal

160 PT

Die 35 Personentage Überhang sind die eigentliche Arbeit des Workshops. Hier wird diskutiert, welche Muss-Anforderung einen Umweg hat. In diesem Beispiel könnte das die automatische Anbindung an die Buchhaltung sein, die für die ersten drei Monate durch einen wöchentlichen CSV-Export ersetzt wird.

So läuft ein MoSCoW-Workshop

Ein halber Tag reicht für 40 bis 80 Anforderungen, wenn sie vorher geschätzt sind. Ohne Schätzung ist die 60-Prozent-Regel nicht anwendbar, und der Workshop wird zur Meinungsrunde. Hilfreich ist eine Aufwandsschätzung als Spanne vorab.

1. Alle Anforderungen starten als Won’t. Jede muss sich ihre Kategorie verdienen.
2. Erst die Muss-Kandidaten mit den Testfragen prüfen.
3. Aufwand der Muss-Gruppe summieren und gegen 60 Prozent halten.
4. Überhang herunterstufen, bis die Grenze passt.
5. Soll und Kann nach Nutzen pro Aufwand sortieren.
6. Ergebnis schriftlich festhalten, mit Datum und Namen der Entscheider.

Schritt eins wirkt radikal. Er dreht aber die Beweislast um, und das spart Stunden.

Woran MoSCoW in der Praxis scheitert

Der häufigste Fehler ist eine Muss-Quote von 80 oder 90 Prozent, die trotzdem durchgewinkt wird. Dann ist die Methode Dekoration. Die Einteilung sieht ordentlich aus, schützt aber nicht vor dem Moment, in dem das Budget knapp wird und nichts mehr verschiebbar ist.

Der zweite Fehler: Die Kategorien werden ohne Nutzerbezug vergeben. Wer Anforderungen als User Stories mit klarem Nutzen formuliert, hat es leichter, weil der „damit“-Teil zeigt, was ohne die Funktion schiefläuft. Eine Zeile wie „Exportfunktion“ lässt sich dagegen beliebig hoch oder niedrig einstufen.

Drittens wird die Einteilung im Projektverlauf still unterlaufen. Neue Wünsche landen direkt im Muss, ohne dass etwas anderes herausfällt. Jede neue Muss-Anforderung braucht deshalb eine Gegenbuchung: Was rutscht dafür nach unten? Genau das regelt ein sauberer Change-Request-Prozess.

Grenzen der Methode

MoSCoW sagt nichts darüber, in welcher Reihenfolge Muss-Anforderungen umgesetzt werden. Dafür braucht es technische Abhängigkeiten und Risiko. Riskante Punkte, etwa eine unbekannte Schnittstelle, gehören früh in den Plan, auch wenn sie fachlich gleich wichtig sind wie andere.

Zweitens neigen Teams dazu, Kategorien nie zu überprüfen. Eine Anforderung, die im März ein Soll war, kann im Juni durch eine Gesetzesänderung zum Muss werden. Sinnvoll ist ein Blick auf die Einteilung bei jedem Release, in Scrum etwa beim Backlog Refinement.

Wer eine feinere Rangfolge braucht, kombiniert MoSCoW mit einem Punktesystem wie RICE oder WSJF innerhalb der Kategorien. Für die meisten mittelgroßen Projekte ist das überdimensioniert.

MoSCoW und Verträge

Bei Festpreisprojekten ist die Einteilung bares Geld wert. Wenn im Vertrag steht, dass Muss-Anforderungen fest geschuldet sind und Soll sowie Kann im Rahmen des Budgets umgesetzt werden, hat das Projekt eingebaute Flexibilität. Wie solche Modelle aussehen, beschreibt der Beitrag Festpreis oder Time and Material.

Die Kategorien helfen auch beim Schreiben selbst. Wer im Lastenheft jede Anforderung mit M, S, C oder W kennzeichnet, liefert Anbietern eine Grundlage, auf der sie gestaffelt anbieten können.

Ein Entwicklungspartner wie OnlineBuilders kann bei der Aufwandsschätzung je Anforderung helfen, damit die 60-Prozent-Grenze auf realistischen Zahlen beruht und nicht auf Bauchgefühl.

Nächster Schritt: Markier in deiner Anforderungsliste alles, was heute als Muss gilt, und addier den geschätzten Aufwand. Liegt die Summe über 60 Prozent des Budgets, weißt du, worüber im nächsten Termin gesprochen werden muss.

Häufige Fragen

Wofür stehen die Buchstaben in MoSCoW?

M für Must have, S für Should have, C für Could have und W für Won't have this time. Die beiden kleinen o haben keine Bedeutung, sie machen das Kürzel nur aussprechbar.

Wer entscheidet, was ein Must have ist?

Die Fachseite mit Budgetverantwortung, also meist Product Owner oder Auftraggeber. Die Entwicklung liefert die Aufwandsschätzung und weist auf Abhängigkeiten hin, entscheidet aber nicht über den fachlichen Wert.

Ist MoSCoW für agile Projekte geeignet?

Ja, die Methode stammt sogar aus dem agilen Umfeld. Sie wurde vom DSDM-Framework übernommen und lässt sich pro Release, pro Sprint oder für das ganze Projekt anwenden.

Was ist der Unterschied zwischen Won't have und Streichen?

Won't have heißt „nicht in diesem Zeitraum“. Die Anforderung bleibt dokumentiert und kann in einem späteren Release wieder auftauchen. Das schafft Ruhe, weil niemand das Gefühl hat, sein Wunsch sei verloren.