4.8 6 Votes
Artikel-Rating

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.

Woher kommt das MoSCoW-Prinzip?

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.

Was bedeutet das MoSCoW-Prinzip?

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

  • Must Have

  • Should Have

  • Could Have

  • Won’t Have (this time)

Backlog Priorisierung nach dem MoSCoW Prinzip

Must Haves

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:

  • Was passiert, wenn dieses Feature nicht enthalten ist?

  • Gäbe es einen Workaround?

  • Funktioniert unser Produkt (grundsätzlich) auch ohne dieses Feature?

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.

Should Haves

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.

Could Haves

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.

Won’t Haves (this time)

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 in der Praxis

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.

Hilfe zur Priorisierung  des Product Backlogs

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.

Unterstützung beim Forecast

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.

  • Du kennst die Velocity Range (noch) nicht? In meinem Artikel über Burndown Charts findest Du hierzu mehr Infos und Details.

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.

MoSCoW-Prioriserung Velocity Range
Summe der Story Points aller Must Haves Minimale Velocity
Summe der Story Points aller Must Haves & Should Haves Median
Summe der Story Points aller Must Haves, Should Haves & Could Haves Maximale Velocity

Stellst Du beispielsweise fest, dass die Summe aller Must-Have-Features bei 90 SP liegt, die Summe aller Should Haves bei 80 SP und die Summe aller Could-Have-Features 60 SP, sähe diese Tabelle folgendermaßen aus:

MoSCoW-Prioriserung Velocity Range
90SP (Must Haves) 70 SP (Minimale Velocity)
170 SP (Must Haves & Should Haves) 120 SP (Median)
230 SP (Must Haves, Should Haves & Could Haves) 180 SP (Maximale Velocity)

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

  • Weil die minimale Velocity (für 10 Sprints) lediglich 70 SP beträgt, könnte es (schlimmstenfalls) passieren, dass nicht alle Must Haves rechtzeitig umgesetzt werden können.

  • Gehst Du vom Median-Wert aus, stehen die Chancen noch recht gut, dass alle Must Haves umgesetzt werden können. Die Wahrscheinlichkeit, dass Should Haves fehlen werden, ist jedoch schon deutlich größer. Die Summe von Must Haves und Should Haves liegt bei 170 SP, während der Median Deines Teams lediglich bei 120 SP liegt. Nur falls Dein Team regelmäßig sehr viel umsetzen wird (maximale Velocity), sind alle Should Haves machbar.

MoSCoW-Priorisierung und Veloctiy Range
  • Die Could Haves werden beim aktuellen Stand höchstwahrscheinlich nicht bis zum Ende des 10. Sprint voll umgesetzt werden können. Zusammen mit Must Haves und Should Haves beläuft sich der Umfang auf 230 SP. Die maximale Velocity liegt jedoch nur bei 180 SP.

MoSCoW-Priorisierung festlegen

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

Damit die Priorisierung, die dadurch entsteht, auch von allen akzeptiert wird, solltest Du sie stets im direkten Austausch mit Deinen Kunden und Stakeholdern festlegen.
0
Bindest Du derzeit schon Stakeholder in die Priorisierung Deines Backlogs ein? Wie gehst Du dabei vor?x
  • Ganz besonders gut dazu eignet sich ein sogenannter User-Story-Mapping-Workshop, den Du zu Beginn Deines Projektes beziehungsweise Deiner Produktentwicklung durchführst.

  • Auch das Innovation Game Buy a Feature kann hilfreich sein, um Dein Backlog nach dem MoSCoW-Prinzip zu priorisieren.

Alternativen zum MoSCoW-Prinzip

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

  • Eine erste mögliche Alternative ist die WSJF-Methode (Weighted Shortest Job First). Sie ist insbesondere dann hilfreich, wenn Verzögerungskosten eine wichtige Rolle spielen.

  • Eine weitere Möglichkeit mehr Struktur in die Priorisierung Deines Backlogs zu bringen, ist das populäre Kano-Modell. Es hilft Dir dabei, welche Deiner potenziellen Produkt-Features Kundenzufriedenheit erzeugen und welche nicht.

Fazit zum MoSCoW-Prinzip

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!