Was ist die MoSCoW-Technik?
Die MoSCoW-Methode ist eine Priorisierungstechnik, die im Management, in der Business-Analyse, im Projektmanagement und in der Softwareentwicklung eingesetzt wird, um mit den Stakeholdern ein gemeinsames Verständnis über die Wichtigkeit zu erreichen, die sie der Erfüllung der einzelnen Anforderungen beimessen; sie ist auch als MoSCoW-Priorisierung oder MoSCoW-Analyse bekannt. Die MoSCoW-Priorisierungstechnik spielt eine Schlüsselrolle im Agilen Projektmanagement. In einem agilen Projekt ist es wichtig, die Wichtigkeit der verschiedenen Dinge zu verstehen. Da Zeit eine feste Ressource ist, wird die Priorisierung auf Anforderungen, Aufgaben, Produkte, Benutzerfälle usw. angewendet. Seien Sie sehr vorsichtig, dies ist keine agile Technik (dazu gehören Scrum, Kanban, XP usw.), jedoch ist diese Technik in Agile weit verbreitet. In fast allen Zertifizierungen gibt es Fragen zur MoSCoW-Technik.
Der Begriff MoSCoW selbst ist ein Akronym, das sich aus den Anfangsbuchstaben jeder der vier Priorisierungskategorien (Must have, Should have, Could have und Won’t have) zusammensetzt, wobei die dazwischenliegenden Os hinzugefügt werden, um das Wort aussprechbar zu machen. Während die Os in der Regel klein geschrieben werden, um anzuzeigen, dass sie für nichts stehen, wird auch das MOSCOW in Großbuchstaben verwendet.
Priorisierung von MoSCoW-Anforderungen
Alle Anforderungen sind wichtig, aber sie werden priorisiert, um den größten und unmittelbarsten Geschäftsnutzen früh zu liefern. Die Entwickler werden zunächst versuchen, alle „Muss“-, „Sollte“- und „Könnte“-Anforderungen zu liefern, aber die „Sollte“- und „Könnte“-Anforderungen werden als erste entfernt, wenn der Zeitplan für die Lieferung bedroht ist.
Muss
Diese stellen die minimale nutzbare Teilmenge (MUS) der Anforderungen dar, die das Projekt garantiert liefern muss. Dies kann durch einige der folgenden Punkte definiert werden:
Kann ohne dies nicht zum Zieldatum geliefert werden
Es macht keinen Sinn, zum Zieldatum zu liefern; wenn es nicht geliefert wird, macht es keinen Sinn, die Lösung zum vorgesehenen Datum einzusetzen
Nicht legal ohne dies
Ungefährlich ohne dies
Kann den Business Case nicht liefern ohne dies
Stellen Sie die Frage: „Was passiert, wenn diese Anforderung nicht erfüllt wird?“ Wenn die Antwort lautet: „Brechen Sie das Projekt ab – es hat keinen Sinn, eine Lösung zu implementieren, die diese Anforderung nicht erfüllt“, dann ist es eine Must Have-Anforderung. Wenn es eine Möglichkeit gibt, die Anforderung zu umgehen, selbst wenn es sich dabei um eine manuelle Umgehung handelt, dann handelt es sich um eine „Sollte haben“- oder „Könnte haben“-Anforderung. Die Herabstufung einer Anforderung auf „Sollte haben“ oder „Könnte haben“ bedeutet nicht, dass sie nicht erfüllt wird, sondern nur, dass die Erfüllung nicht garantiert ist.
Sollte haben
Wichtig, aber nicht lebenswichtig
Es kann schmerzhaft sein, sie wegzulassen, aber die Lösung ist immer noch praktikabel
Möglicherweise ist eine Umgehung erforderlich, z. B. das Management von Erwartungen, eine gewisse Ineffizienz, eine vorhandene Lösung, Papierkram usw.
Ein „Sollte haben“ kann von einem „Könnte haben“ unterschieden werden, indem man den Grad des Schmerzes betrachtet, der durch die Nichterfüllung verursacht wird, in Bezug auf den Geschäftswert oder die Anzahl der betroffenen Personen.
Könnte haben
Gewünscht oder wünschenswert, aber weniger wichtig
Weniger Auswirkung, wenn es weggelassen wird (im Vergleich zu einem Sollte haben)
Wird diesmal nicht haben
Ein Vorteil der MoSCoW-Methode ist, dass sie mehrere Initiativen in die Kategorie „wird nicht haben“ einordnet. Das hilft dabei, die Erwartungen darüber zu steuern, was in einem bestimmten Release (oder einem anderen Zeitrahmen, für den Sie die Prioritäten setzen) nicht enthalten sein wird.
Initiativen in die Kategorie „Wird nicht benötigt“ zu setzen, ist eine Möglichkeit, eine Ausweitung des Umfangs zu verhindern. Wenn Initiativen in dieser Kategorie sind, weiß das Team, dass sie für diesen bestimmten Zeitrahmen keine Priorität haben sollen. Einige Initiativen in der „Wird-nicht-haben“-Gruppe werden in der Zukunft priorisiert werden, während andere wahrscheinlich gar nicht passieren werden. Manche Teams entscheiden sich, zwischen diesen zu unterscheiden, indem sie eine Unterkategorie innerhalb dieser Gruppe erstellen.
Zusammenfassung
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) wird vor allem zur Priorisierung von Anforderungen verwendet, obwohl die Technik auch in vielen anderen Bereichen nützlich ist. Atern empfiehlt für ein Projekt nicht mehr als 60 % Aufwand für Must Haves, mit 40 % Shoulds und Coulds. Alles, was höher als 60 % ist, stellt ein Risiko für den Erfolg und die Vorhersagbarkeit des Projekts dar, es sei denn, die Umgebung ist gut verstanden, das Team ist etabliert und die externen Risiken sind minimal.