Möchtest du eine benutzerdefinierte Priorisierungsmethode in deinen Jira-Projekten verwenden? Die MoSCoW-Priorisierung kann einfach mit dem Jira-Prioritätsfeld implementiert werden – ich zeige dir, wie das geht.

Es gibt verschiedene Priorisierungsmethoden, aber die MoSCoW-Methode bietet einen einfachen Einstieg. Weitere Methoden sind: RISE, Kano-Modell, Value Proposition oder Impact vs. Effort. Ich nutze gerne die RISE-Methode und gelegentlich die MoSCoW-Methode – je nach Projekt und Geschäftsanforderungen.

Eine kürzlich durchgeführte Umfrage auf LinkedIn zeigt, dass diese Methoden auch unter Produkt- und Projektmanagern am beliebtesten sind.

Aktuelle LinkedIn-Umfrage zur Beliebtheit von Priorisierungsmethoden

Aktuelle Umfrage auf LinkedIn zur Beliebtheit von Priorisierungsmethoden

Was ist die MoSCoW-Priorisierung?

Diese Priorisierungsmethode wurde 1994 von Dai Clegg entwickelt und erstmals umfassend in DSDM (Dynamic Systems Development Method) eingesetzt. Die MoSCoW-Priorisierung ist eine beliebte Technik zur Verwaltung von Anforderungen und ihrer Bedeutung für das Projekt.

Das Akronym MoSCoW steht für vier Kategorien von Anforderungen: Must-have (muss sein), Should-have (sollte sein), Could-have (könnte sein) und Won’t-have (wird vorerst nicht umgesetzt). Schauen wir uns diese Kategorien genauer an.

1. Must-have

Diese Anforderungen bilden das Minimal nutzbare Set (MUST) und müssen unbedingt geliefert werden. Typische Kriterien für Must-haves:

  • Ohne diese Funktion kann das Projekt nicht termingerecht geliefert werden.
  • Es wäre ohne diese Funktion rechtlich oder sicherheitstechnisch unzulässig.
  • Ohne diese Funktion ist keine brauchbare Lösung möglich.

2. Should-have

Should-have-Anforderungen sind definiert als:

  • Wichtig, aber nicht zwingend erforderlich.
  • Schmerzhaft, aber tragbar, wenn sie weggelassen werden, da die Lösung dennoch funktionsfähig bleibt.

3. Could-have

Could-have-Anforderungen sind definiert als:

  • Erwünscht oder nützlich, aber weniger wichtig.
  • Geringere Auswirkungen, falls sie nicht umgesetzt werden (verglichen mit Should-haves).

4. Won’t-have

Das Team hat sich darauf geeinigt, dass diese Anforderungen nicht im aktuellen Projektumfang umgesetzt werden. Sie werden dokumentiert, um eine spätere inoffizielle Wiedereinführung zu vermeiden. Diese Kategorie hilft, den Fokus auf die wichtigsten Anforderungen zu behalten.

Balance der Prioritäten

Bei der Entscheidung, wie viel Aufwand für Must-have-Anforderungen eingeplant wird, sollte bedacht werden, dass alle anderen Anforderungen als Puffer dienen. Die Must-haves definieren das Minimal nutzbare Set, das garantiert geliefert wird.

Die priorisierten Anforderungen können Teil eines Meilensteinplans oder einer Roadmap sein. Während die Must-haves die Kernfunktionalität sicherstellen, sind die Should-haves und Could-haves flexibler und können während der Entwicklung angepasst werden.

Ein guter Ausgangspunkt

Unter Berücksichtigung des Projektumfangs, Budgets und der Zeitvorgaben sollten nicht mehr als 60 % des Gesamtaufwands auf Must-haves entfallen, um realistische Planung zu gewährleisten.

Projektanforderungen nach Priorität geordnet

Ein sinnvoller Anteil an Could-haves (ca. 20 %) stellt sicher, dass diese Anforderungen nur umgesetzt werden, wenn die Zeit es erlaubt. Der Fokus liegt jedoch weiterhin darauf, Must-haves und Should-haves pünktlich bereitzustellen.

Integration der Priorisierung in Jira

Die MoSCoW-Priorisierung kann in Jira durch neue Prioritätswerte für Tickets umgesetzt werden. Dazu navigierst du in den Einstellungen für Vorgänge, indem du oben rechts auf das Zahnrad klickst.

Einstellungen für Vorgänge öffnen

Einstellungen für Vorgänge öffnen

Anschließend klickst du auf die Option Prioritäten, um die aktuelle Prioritätsliste anzuzeigen.

Zur Prioritäten-Seite navigieren

Zur Prioritäten-Seite navigieren

Hier kannst du nun neue Prioritäten mit den folgenden Einstellungen erstellen:

Neue Jira-Prioritäten erstellen

Neue Jira-Prioritäten erstellen

Titel Beschreibung Farbe URL
MUST Minimal nutzbares Set an Anforderungen. Ohne sie kann nicht geliefert werden. #61bd4f https://raw.githubusercontent.com/Herndl/jiraicons/master/must.png
SHOULD Wichtig, aber nicht essenziell; Weglassen wäre schmerzhaft, aber tragbar. #f2d600 https://raw.githubusercontent.com/Herndl/jiraicons/master/should.png
COULD Erwünscht oder nützlich, aber weniger wichtig; geringere Auswirkungen, falls weggelassen. #ff9f1a https://raw.githubusercontent.com/Herndl/jiraicons/master/could.png
WON’T Wird vorerst nicht umgesetzt. #eb5a46 https://raw.githubusercontent.com/Herndl/jiraicons/master/wont.png

Alle Icons hier herunterladen…