Methodische Priorisierung mit der MoSCoW-Methode

Prioritäten setzen heißt auswählen, was liegenbleiben soll.

Helmar Nahr (*1931), dt. Mathematiker u. Wirtschaftswissenschaftler

Ob im klassischen oder agilen Projektkontext – wer die Fokuspunkte nicht kennt und nicht weiß, was für den Erfolg wichtig ist, agiert blind. Für alle Projektbeteiligten ist es immens wichtig, Schwerpunkte transparent kommuniziert zu bekommen. Der Weg dahin ist allerdings oft nicht einfach. Angefangen bei nicht vollständigem Wissen über die Kernanforderungen des geplanten Produkts bis hin zum Alles-Ist-Wichtig-Klassiker: wie können wir diese Knoten lösen und zu einer vernünftigen Priorisierung der zu realisierenden Anforderungen kommen?

Gerade bei großen und fachbereichsübergreifenden Projekten und Produkten ist die Einbeziehung wichtiger Stakeholder aus eben diesen Fachbereichen immens wichtig. Wir können die Einordnung im Rahmen eines Workshops vornehmen oder von jedem Stakeholder einzeln einfordern.

Wir empfehlen ausdrücklich die gemeinsame Erarbeitung dieser Anforderungspriorisierung in Form eines Workshops. Hier haben wir die Möglichkeit, Austausch und Transparenz zwischen den Stakeholdern zu gewährleisten und zu fördern. Nur so erlangen wir eine grundlegende Akzeptanz gegenüber den Anforderungen aus anderen Fachbereichen.

Ein wichtiger Hinweis: Du wirst auf dem Weg zu einer Priorisierung oft neue Anforderungen identifizieren, die allein durch die Kommunikation zwischen den Projektbeteiligten ans Tageslicht treten. Diese sollten in keinem Fall auf einen Berg von „noch zu besprechenden Themen“ gelegt werden! Versuche, diese neuen Anforderungen sofort klar und eindeutig zu dokumentieren und füge sie dem Pool der noch zu priorisierenden Themen hinzu. So vermeidest Du eine unter Umständen sehr zeitaufwändige Nachpriorisierungsrunden.

Wir wollen in diesem und folgenden Artikeln ausgewählte Methoden zur Priorisierung vorstellen. Das Ergebnis ist jeweils ein transparent definierter Projektumfang oder eine grobe Themenpriorisierung eines Product Backlogs.

Übrigens: wie Du überhaupt zu einem priorisierbaren Themenpool kommst werden wir Dir in separaten Artikeln vorstellen.

MoSCoW

Diese Methode ist hilfreich für eine Einordnung nach Kritikalität. MoSCoW steht hierbei als Akronym für die englischen Wörter „Must“, „Should“, „Could“ und „Would/Won’t/Want“. Zu den ersten Buchstaben dieser Wörter gesellen sich die zwei „o“. Diese haben allerdings keine Bedeutung und dienen einzig dem Zweck, einen aussprechbaren Begriff zu formen.

Mit der MoSCoW-Methode ordnen wir Anforderungen in die genannten Kategorien ein. Dies kann auf unterschiedlichste Art und Weise geschehen.

Bei kleinem Projektumfang gelingt dies auch mit Klebezettel oder einer Pinnwand. Zeichne ein Raster, welches die Einordnung ermöglicht. Schreibe die Anforderungen oder Themen mit gewünschter Flughöhe auf die Zettel und ordne diese nach gründlicher Diskussion ein.

Bei einem umfangreichen Themen-/Anforderungspool wirst Du diese Informationen im besten Fall übersichtlich, vielleicht sogar tabellarisch, dokumentiert haben. In diesem Fall benötigst Du nur eine weitere Spalte, in welche Du die jeweilige Zuordnung eintragen kannst. Der Vorteil einer tabellarischen Dokumentation ist zum Beispiel die Filter- und Sortierbarkeit. Nutze entsprechende Tools, z.B. den Klassiker Excel, und dokumentiere ab den ersten Gesprächen mit Stakeholdern klar und deutlich.

Stelle die Ergebnisse der Priorisierung jedem Stakeholder zur Verfügung. Du garantierst damit Transparenz und vermeidest „böse Überraschungen“ im Projektverlauf.

Führe Einigkeit bzgl. der Bewertung einzelner Kategorien herbei! Allen Stakeholdern muss klar sein, dass eine „Could“-Anforderung unter Umständen nicht im Projektumfang berücksichtigt werden kann. Dies bedeutet aber nicht, dass diese nicht in einem weiteren Release bereitgestellt werden kann!

Must

Anforderungen der Kategorie „Must“/“Muss“ sind selbstredend als absolut notwendig anzusehen und sind für den Erfolg des Produkts/Projekts ausschlaggebend. Hier sind Nice-To-Have-Features genauso falsch wie Anforderungen, die sich gut auf einen zukünftigen Release verschieben lassen. Nur Anforderungen, die absolut kritisch in Bezug auf die Akzeptanz der Stakeholder und der Zielgruppe eingeordnet wurden, sollten sich in dieser Kategorie finden lassen.

Vereinfacht: Welchen Nutzen hat ein Online-Shop, in welchem ich keine Lieferadresse angeben kann? Was nutzt mir ein Terminverwaltungsprogramm, welches keine ordentliche Verwaltung eben dieser Termine zulässt? Produkte ohne zentrale und notwendige Funktionen verfehlen ihr Ziel.

Anforderungen dieser Kategorie, die zum Projektabschluss nicht umgesetzt wurden, beeinträchtigen in der Regel die Akzeptanz des Produkts/Projekts. Unter Umständen gilt das Projekt auch als gescheitert – je nach Kritikalität.

Achte darauf, dass höchstens 60 Prozent der Anforderungen in diese Kategorie eingeordnet werden. Dies variiert natürlich sehr nach Vorhaben und Flughöhe dieser Anforderungen. Setze Dir individuelle Ziele, um das Projekt gut planen zu können.

Hier sei nochmal der Hinweis gestattet: ein Anforderungspool, der nur aus absolut wichtigen Themen besteht, ist in der Regel unvollständig oder nicht gut analysiert!

Should

„Should“/“Soll“ ist als Kategorie kritischer und wichtiger Anforderungen zu betrachten. Diese Anforderungen tragen sehr zur Akzeptanz und dem Erfolg bei und sind auf jeden Fall erstrebenswert. Sie sind jedoch bei Nicht-Erfüllung keine Show-Stopper und führen nicht unweigerlich zum Fehlschlag. Im einfachsten Fall können diese Anforderungen „nachgereicht“ werden.

Vereinfachtes Beispiel: Neben den Hauptzahlungsmethoden soll eine weitere Zahlungsmethode angeboten werden. Auch wenn es aus strategischer Sicht sinnvoll ist, diese Zahlungsmethode anzubieten, ist sie nicht für einen Bestellabschluss oder die Funktionalität des Online-Shops entscheidend.

Anforderungen in dieser Kategorie sind sehr oft Kandidaten für ein zukünftiges Release. Dies schafft Platz für die Kategorie „Must“ und macht ein Projekt planbarer. Achte darauf, dass ungefähr 20 bis 30 Prozent der Anforderungen in diese Kategorie einfließen. Auch dies ist natürlich wieder abhängig von allerlei Rahmenbedingungen.

Could

Anforderungen, die nicht ausschlaggebend für einen Erfolg sind, sind die klassischen Nice-To-Have-Features, die in der „Could“/“Kann“-Kategorie eingeordnet sind. Dies bedeutet aber nicht, dass diese „wertlos“ sind. Lässt es die Ressourcenplanung zu, sollten auch diese Anforderungen umgesetzt werden. Sie steigern oft die Akzeptanz – und schon aus diesem Grund sollten sie nicht einfach ersatzlos gestrichen werden.

Vereinfachtes Beispiel: Wenn sich der Kunde im Online-Shop anmeldet, kann er personalisierte Produktvorschläge angezeigt bekommen. Dies führt zu einer höheren Akzeptanz des Shops, führt aber bei einer Nicht-Erfüllung der Anforderung nicht zur Beeinträchtigung der grundlegenden Funktionalität der Plattform.

10 bis 20 Prozent der Anforderungen sollten Kann-Anforderungen sein. Dies ist wie oben schon erwähnt abhängig von vielen Faktoren.

Won’t

Ob „Would“, „Won’t“ oder „Want“ – klar definiert ist das „W“ nicht. Klar ist jedoch, dass diese Kategorie alle Anforderungen umfassen sollte, die in der momentanen Projektbetrachtung ausgeschlossen werden. Daher nutzen wir meistens “Won’t” als Erklärung. Dies bedeutet nicht, dass sie zukünftig keine Rolle mehr spielen werden! Gerade in dynamischen Märkten können sich Prioritäten schneller ändern wie manchem Product Owner oder Projektmanager lieb ist.

Diese Kategorie kann auch für eine generelle Abgrenzung von nicht umzusetzenden Anforderungen bzw. Features gegenüber dem geplanten Projektumfang genutzt werden. Oft wird der Aufwand der Dokumentation dafür in Frage gestellt, da diese Themen ohnehin nicht weiterverfolgt werden. Wir weisen darauf hin, dass diese Informationen klar zur Transparenz und zum Verständnis beitragen! Im einfachsten Fall erbringst Du so den Nachweis, dass man Features nicht vergessen, sondern diese mit Bedacht aus der Planung herausgehalten hat. Die Information, dass ein Feature nicht umgesetzt wird, ist ebenso wichtig, wie ein Projektplan, der alle umzusetzenden Funktionalitäten aufzeigt!

Vereinfacht: Der Online-Shop soll keine Sprachauswahl „Chinesisch“ anbieten, da dieser Markt aktuell schlicht irrelevant ist.

Fazit

Nutze die Möglichkeiten einer Priorisierung mittels der vorgestellten MoSCoW-Methode um Dein Vorhaben klarer umreißen zu können. Eine transparente Benennung der Prioritäten ist die Basis für eine erfolgreiche Planung und Realisierung Deines Produkts/Projekts! Und das völlig unabhängig davon, ob Du klassisch oder agil planst.

Der nächste logische Schritt wäre der Aufbau eines Product Backlogs oder die Definition eines Projektscopes. Durch die Einordnung der Anforderungen haben wir uns selbst Leitplanken gesetzt, sodass dieser Schritt nun erheblich einfacher fallen sollte.

Mehr Informationen findest Du unter: https://de.wikipedia.org/wiki/MoSCoW-Priorisierung