Aufgaben priorisieren mit der MoSCoW-Methode

Die Festlegung des Umfangs, der Fristen und des Budgets eines Projekts ist für die Projektplanung von entscheidender Bedeutung. Die richtige Definition dieser Schlüsselmerkmale ermöglicht es Ihrem Projektteam, sich auf klar definierte Projektziele und eine Vision zu konzentrieren. Außerdem sollte keine Zeit für unnötige Aufgaben verschwendet werden, damit das Projekt innerhalb der Fristen bleibt.

Die MoSCoW-Methode ist deswegen eine hilfreiche Methode, die gleichzeitig die Qualität und den Fokus Ihres Projekts bewahrt. Sie hilft dabei, die Anforderungen eines Projekts zu priorisieren und die Funktionalitäten zu sortieren, die in der endgültigen Version oder dem Produkt implementiert werden sollen.

Lesen Sie weiter, um mehr über die Anwendung des MoSCoW-Prinzips mit seinen Vor- und Nachteilen und Alternativen zu erfahren.

Diese Methode basiert auf einer Eselsbrücke: Das Akronym MoSCoW soll an Aktionsverben erinnern — und nicht an der russischen Hauptstadt. Das MoSCoW-Prinzip wurde von Dai Clegg entwickelt, der ebenfalls eine wichtige Rolle bei der Entwicklung der ersten agilen Methoden in Form der Dynamic Systems Development Method (DSDM) spielte.

Diese Priorisierungsmethode kann für so gut wie alles verwendet werden, wird aber am häufigsten für die Projektplanung agiler Projekte eingesetzt, um User Stories und technische Anforderungen zu priorisieren. Die Grundsätze sind einfach: Nicht alle Anforderungen des Projekts sind für seinen Erfolg wichtig. Es gibt Anforderungen, die das Projekt:

• M = Must have (haben muss)
• S = Should have (haben sollte)
• C = Could have (haben könnte)
• W = Won’t have (nicht haben wird)

Die MoSCoW-Methode dient zur Priorisierung von Anforderungen anhand von 4 Kennzeichnungen, die wir nachfolgend erläutern werden.

Diese Kategorie ist für Elemente reserviert, die für den Erfolg des Projekts unerlässlich sind. Sie können nicht ersetzt werden und definieren das Projekt global. Must-haves sollten Folgendes beinhalten:

• Jede Feature, die aus Compliance-Gründen erforderlich ist. Must-Anforderungen können sich auf die Sicherheit und den Datenschutz beziehen oder gesetzliche Verpflichtungen sein.
• Jede Feature, die nicht weggelassen oder ersetzt werden kann, ohne dass das Produkt unbrauchbar wird. Diese Schlüsselanforderungen sind erforderlich, damit das Produkt die grundlegenden Aufgaben erfüllen kann, für die es entwickelt wurde.

Kurz gesagt, diese Kategorie umfasst alles, was die Freigabe oder den Verkauf des Produkts oder der Software unmöglich machen könnte.

Einige Beispiele sind grundlegende Merkmale wie:

• Die Homepage im Falle einer Website,
• Die Räder, um ein Fahrrad zu bauen,
• Sicherheitsstandards, um eine professionelle Anwendung zu erstellen, usw.

Diese Kennzeichnung unterscheidet sich etwas von der ersten Kategorie. Das Endprodukt braucht keine "Should"-Anforderungen, um funktional und benutzbar zu sein. Diese sollten jedoch im Laufe der Produktentwicklung implementiert werden, da sie einen erheblichen geschäftlichen Mehrwert darstellen.

Einige Beispiele sind Initiativen wie:

• Die Implementierung einer Suchfunktion auf einer Website,
• Die Herstellung eines Fahrrads, das für verschiedene Terrains geeignet ist, usw.

Bei den “Could have”-Anforderungen handelt es sich um Funktionen, die wünschenswert wären, d.h., sie würden dem Projekt einen gewissen geschäftlichen Nutzen bringen, aber weniger als die “Should have”-Funktionalitäten. Sie werden nicht priorisiert, d.h. dass sie solange im Backlog gehalten werden, bis genügend Zeit zur Verfügung steht, um sie zu implementieren. Wenn die Entwicklung der Funktionen aus den ersten beiden Kategorien jedoch länger dauert als erwartet, werden sie zunächst verschoben oder gestrichen.

In einigen Fällen kann es sinnvoll sein, eine Geschäftsanalyse durchzuführen, um den Grad der Wichtigkeit und Priorität einer Anforderung zu bestimmen, da "should" und "could" in einigen Aspekten ähnlich sind.

Diese Gruppe ist die wichtigste, um die Grenzen des Projektumfangs zu definieren. Sie gruppiert die Features, die wahrscheinlich nie implementiert werden, entweder weil sie wenig Wert für Ihr Unternehmen haben oder weil sie zu viel Aufwand bedeuten würden. Oder beides.

Aber nichts ist endgültig festgelegt. Einige dieser Funktionalitäten können zu einem späteren Zeitpunkt priorisiert werden, wenn sie als nützlich eingesehen werden. Manche behaupten, diese Kategorie in zwei Unterabschnitte zu unterteilen, einen für “will not have” (“wird nicht benötigt”) und einen für “will not have this time” (“wird zu diesem Zeitpunkt nicht benötigt”). Auf diese Weise können das Team, der Projektmanager oder der Product Owner sehen, welche Anforderungen dem Sprint Backlog hinzugefügt werden könnten, wenn noch einige Sprints vor der Deadline Zeit übrig sind.

Die Vorteile der MoSCoW-Priorisierung sind vielfältig:

• Die Vision wird deutlicher, da Worte anstelle von Zahlen oder allgemeinen Begriffen wie “High” oder “Low” verwendet werden, um die Priorität zu definieren. Dadurch kann sich das Team auf die zu liefernden Ergebnisse konzentrieren, anstatt sich über sinnlose Prioritätsstufen zu streiten.
• Die Methode lässt keine Unklarheiten zu, ist aber flexibel genug, um einen gewissen Spielraum für Diskussionen über eine Anforderung zu lassen, wenn sich das Team nicht von Anfang an einig ist.
• Die Priorisierung ist intuitiv und leicht zu verstehen, auch für Nicht-Experten. Dies kann besonders bei der Kommunikation mit Auftraggebern / Kunden nützlich sein.

Kurz gesagt, diese Methode ist einfach, verbal und verständlich.

Obwohl die MoSCoW-Methode ein weit verbreitetes und recht beliebtes Priorisierungsinstrument ist, ist sie nicht frei von Kritik.

• Die verbale Basis dieser Technik macht sie subjektiver als eine reine Statistik. Sie ist zwar nützlich, um einen Konsens zu erzielen und für Kommunikationszwecke, aber manche finden die Kategorien “should” und “could” zu ähnlich.
• Die Kategorie “won’t have” kann missverständlich sein. Sie sollten entweder:
  • von Anfang an klarstellen, ob es sich um Features handelt, die in einer spezifischen Version nicht enthalten sein werden, oder um Elemente, die komplett gestrichen werden sollten.
  • die Kategorie unterteilen, um diese beiden Arten von Funktionen voneinander zu trennen.
• Es gibt keine native Möglichkeit, Prioritätsstufen für Anforderungen innerhalb derselben Kategorie zu unterscheiden.

Um Prioritäten zu setzen gibt es Alternativen zu der MoSCoW-Methode, sei es für dringende Aufgaben mit der Eisenhower-Matrix oder beim Stakeholder-Mapping mit der Power/Interest-Matrix.

Die MoSCoW-Priorisierung ist eine nützliche Methode zur Definition Ihres Projektumfangs. Es handelt sich dabei um eine intuitive Matrix, die eine Diskussion über die wichtigsten Anforderungen anregen muss und den größten Mehrwert für Ihr Projekt ermöglichen soll.

Um den richtigen Arbeitsaufwand für ein Projekt festzulegen, müssen Sie sich zunächst über Ihre Prioritäten klar werden. Vernachlässigen Sie nicht den Prozess der Priorisierung, um Ihre Sprints zu planen, und schaffen Sie Klarheit, um mit Ihren Stakeholdern zu kommunizieren.

Sind Sie nun bereit, die Anforderungen Ihres Projektes in der richtigen Reihenfolge anzugehen?