Priorisieren nach dem MoSCoW-Prinzip

Eine der wichtigsten Aufgaben für Dich als Product Owner ist es, Dein Product Backlog klar zu priorisieren. Bestenfalls ist es so geordnet, dass durch die Arbeit des gesamten Scrum Teams möglichst viel Wert entsteht. Wie das genau funktionieren soll, verrät Dir der Scrum Guide allerdings nicht. Deshalb stelle ich Dir in diesem Artikel das sogenannte MoSCoW-Prinzip vor. Es ist eine gute Möglichkeit, mehr Ordnung, Struktur und Klarheit in die Priorisierung Deines Backlogs zu bringen.

Die MoSCoW-Methode geht auf Dai Clegg zurück, der sie während seiner Zeit bei Oracle entwickelt hat. Sie ist ein fester Bestandteil des DSDM-Handbuchs (Dynamic System Development Method). Aber da dieses Prinzip im Grunde jede Art von Produktentwicklung oder Projekt angewendet werden kann, in der Deadlines vorhanden sind, hat es eine weite Verbreitung erfahren.

Das MoSCoW-Prinzip teilt die Features Deines Produktes in vier verschiedene Kategorien ein:

Der Begriff Must Have steht auch für Minimum Usable SubseT. Falls (echte) Must Haves fehlen, macht das Dein Produkt vollkommen unbrauchbar oder verurteilt Dein Projekt zum Scheitern. Das können beispielsweise gesetzliche Vorgaben sein oder Sicherheitsvorschriften, die erfüllt sein müssen, damit Dein Produkt überhaupt genutzt werden darf bzw. kann.

Must Haves sind nicht das, was Deine Kunden oder Nutzer glauben bzw. sagen, haben zu müssen!

Folgende Fragen sind hilfreich, um festzustellen, ob etwas wirklich ein Must Have ist oder nicht:

Wenn ein Feature fehlt und es dafür einen Workaround gibt, dann ist es lediglich ein Should Have (oder vielleicht sogar nur ein Could Have). Dabei ist es unerheblich, ob dieser Workaround Probleme, Schmerzen oder Herausforderungen für Deine Nutzer mit sich bringt.

Ein Feature als Should Have oder Could Have zu kategorisieren, bedeutet im Übrigen nicht, dass es zu einem bestimmten Datum nicht enthalten sein wird. Es bedeutet lediglich, dass seine Fertigstellung nicht garantiert ist und Must Haves vorgezogen werden, falls es zeitlich eng wird.

Wie Must Haves sind auch Should Haves sehr wichtige Features Deines Produktes. Ihr (potenzielles) Fehlen führt jedoch nicht dazu, dass Dein Produkt vollkommen unbrauchbar wird. Sind Should Haves nicht vorhanden, wird die Nutzung Deines Produktes schwierig und wenig (bis gar nicht) komfortabel. Ihr Fehlen führt außerdem dazu, dass Deine Nutzer auf einen Workaround zurückgreifen müssen. Aber dadurch wird Dein Produkt eben nicht vollkommen unbrauchbar.

Deshalb sollten nach Möglichkeit alle Should Haves bis zu einer angesetzten Deadline umgesetzt werden können. Falls es zum Ende hin „eng wird“, sollten Must Haves im Sinne der MoSCoW-Priorisierung jedoch stets höher priorisiert werden.

Should Haves unterscheiden sich von Could Haves durch den „Grad an Schmerzen“, der durch ihr Fehlen verursacht würde. Beispielsweise weil mehr Menschen durch ihr Fehlen betroffen wären oder weil der finanzielle Nachteil, der dadurch entsteht, deutlich größer wäre.

Die Could Haves des MoSCoW-Prinzips sind den bereits genannten Should Haves sehr ähnlich. Fehlen Features aus dieser Kategorie, sind die verursachten Schmerzen auf Nutzer-Seite jedoch deutlich geringer. Could Haves sind Merkmale und Fähigkeiten Deines Produktes, die nur dann umgesetzt werden sollten, wenn Deine Produktentwicklung „wie am Schnürchen“ läuft.

Sobald jedoch absehbar wird, dass eine konkrete Deadline schwierig zu halten sein wird, sind Could Haves diejenigen Features, von denen sich Nutzer und Kunden am ehesten trennen können.

Das letzte Element der MoSCoW-Priorisierung sind die sogenannten Won’t Haves. Won’t Haves sich diejenigen Features Deines Produktes, von denen Du jetzt schon weißt, dass sie bis zu einer konkreten Deadline nicht umsetzen werden können. Sie sind weit unwichtiger als Could Haves und steuern wenig (bis gar nichts) zu Kundenzufriedenheit, User Experience oder dem generellen Nutzen Deines Produktes bei.

Höchstwahrscheinlich existieren für diese fehlenden Features bereits andere praktikable Lösungen, auf die Nutzer Deines Produktes zurückgreifen können, sodass Ihr Fehlen keinerlei Nachteil für sie bedeutet.

Das MoSCoW-Prinzip unterstützt Dich als Produkt Owner vor allem in zweierlei Hinsicht. Zum einen hilft es Dir dabei, Dein Product Backlog zu priorisieren. Zum anderen kannst Du damit auch den Forecast für Deine Stakeholder transparenter gestalten.

Hast Du die Features Deines Produktes (gemeinsam mit Deinen Stakeholdern, Nutzern und Kunden) einer der vier Kategorien des MoSCoW-Prinzips zugeordnet, bist Du ziemlich leicht in der Lage, Dein Product Backlog entsprechend zu sortieren. Denn Du brauchst nicht mehr zu tun, als sie in der entsprechenden Reihenfolge anzuordnen.

Natürlich wird es in der Praxis immer mal wieder Diskussionen zu dieser Priorisierung geben oder bestimmte Dinge werden aus anderen Gründen vorgezogen werden (müssen). Die MoSCoW-Priorisierung bietet Dir als Product Owner jedoch eine gute Argumentationsbasis mit Deinen Stakeholdern.

Falls Du bei der Abarbeitung von Aufwänden nicht nur mit einer durchschnittlichen Velocity arbeitest, sondern die Velocity Range anwendest, kannst Du diese wunderbar mit dem MoSCoW-Prinzip kombinieren.

Stell Dir vor, die letzten 9 Sprints hatte Dein Scrum Team Velocity-Werte von 10, 12, 6, 18, 14, 13, 21, 7 und 8. Damit beträgt die Minimale Velocity 7, der Median 12 und die Maximale Velocity 18. (Der Velocity Range Calculator nutzt zur Berechnung der minimalen und maximalen Velocity lediglich den zweitniedrigsten bzw. zweihöchsten Velocity-Wert.)

Wenn Du weiter annimmst, dass Du gemeinsam mit Deinem Team noch 10 Sprints zur Verfügung hast, gehst Du auf Basis der Velocity Range davon aus, dass mindestens 70 SP abgearbeitet werden können, im Mittel etwa 120 SP, maximal jedoch 180 SP.

Nun kannst Du die minimale Velocity, den Median und die maximale Velocity mit den Must Haves, Should Haves und Could Haves des MoSCoW-Prinzips in Relation setzen.

Mit diesen Ergebnissen der MoSCoW-Priorisierung kannst Du nun einige hilfreiche Überlegungen anstellen.

Natürlich solltest Du als Product Owner die MoSCoW-Priorisierung nicht alleine im „stillen Kämmerlein“ festlegen.

Dir gefällt die MoSCoW-Priorisierung nicht? Dann wirf doch einen Blick auf meinen Artikel

Soviel von meiner Seite zum MoSCoW-Prinzip und wie Du es als Product Owner gewinnbringend einsetzen kannst. Ich hoffe, ich konnte Dir zeigen, dass diese Methode sehr hilfreich sein kann, um mehr Struktur & Ordnung in Dein Product Backlog zu bringen.

Solltest Du noch Fragen zur MoSCoW-Methode haben, schreib mir wie immer gerne einen Kommentar hier unten auf der Seite! Ich freu mich auf Dein Feedback!