MoSCoW-Methode: Intuitiv verständliche Priorisierungen – auch in Jira sichtbar

Wie wichtig ist eine Arbeit für das Release oder den Projektschritt?

Kein Team kommt ohne eine sinnvolle Priorisierung seiner anstehenden Aufgaben und Arbeiten aus, wenn es auch nur halbwegs effizient agieren und bei der Entwicklung eines Releases oder Projekts nicht an den Bedürfnissen der Kunden vorbeirauschen will.

Ideen und Anforderungen kommen aus jeder Ecke. Sie entstehen natürlich im Team selbst, außerdem reichen Kunden Feature-Anfragen ein, Konkurrenzanalysen ergeben neue Erkenntnisse, Stakeholder haben Wünsche und so weiter. Das Backlog eines durchschnittlichen Produktteams umfasst dutzende, wenn nicht hunderte Ideen – und wenn das Team hier keine sinnvolle Differenzierung hineinbringt, kann es auch keine sinnvolle Release- oder Projektplanung vornehmen. Eine zielführende Weiterentwicklung wäre kaum möglich.

Doch Versuche, all die Ideen in diskreten Reihenfolgen zu priorisieren – beispielsweise in Form von Buchstaben (A, B, C, D, ...) oder Zahlen (1 bis 10, 1 bis 100 o. ä.) –, werden das Team nicht weiterbringen und spätestens dann scheitern, wenn die Dinge etwas komplexer werden. Das haben wir in unserem Blogpost zur Priorisierung nach der WSJF-Methode bereits dargestellt.

Während es beim WSJF darum geht, mit möglichst wenig Aufwand möglichst viel Wert zu generieren, widmet sich die MoSCoW-Methode der tatsächlichen Wichtigkeit und Bedeutung einer Funktion oder Story für ein Release oder Projekt, unabhängig vom Umfang der nötigen Arbeit.

Vier klare Prioritäten

Ist Aufgabe X essenziell für das Release, nettes Beiwerk oder gar (zunächst) verzichtbar? Der MoSCoW-Ansatz gibt darauf eine klare Antwort.

In diesen griffigen Akronym stehen die Majuskeln für:

M = Must (have)
S = Should (have)
C = Could (have)
W = Won’t (have)

Eine Must-Anforderung ist eine Aufgabe, die auf jeden Fall umgesetzt werden muss. Es handelt sich um eine Pflichtanforderung. Das Release oder Projekt benötigt diesen Arbeitsschritt ohne Wenn und Aber, er ist nicht verhandelbar. (In diesem Zusammenhang ist es natürlich wichtig, dass sich Must-Features nicht gegenseitig beeinträchtigen oder ausschließen.)

Should heißt, dass die Arbeiten erledigt werden sollten, sobald die Must-Anforderungen abgeschlossen sind. Should-Funktionen sind wichtig, aber nicht essenziell für die Auslieferung. Da die Priorität niedriger ist als die der Must-Anforderungen, werden sie im Zweifel nachgeordnet behandelt (und beispielsweise auf ein späteres Release verschoben).

Could-Anforderungen sind nachrangig. Es wäre ganz schön, wenn es diese Funktionen gäbe, aber die Umsetzung ist für den Erfolg des Release oder des Projektschritts nicht erforderlich. Sie finden nur Einzug, wenn alle höher priorisierten Arbeiten umgesetzt sind.

Won’t-Arbeiten haben die niedrigste Priorität. Sie werden im aktuellen Release oder Projekt nicht umgesetzt. Das muss nicht zwangsläufig bedeuten, dass das Feature grundsätzlich unwichtig und verzichtbar ist. Allerdings ist die Umsetzung nicht zeitkritisch und kann zu einem späteren Zeitpunkt erneut betrachtet werden.

Gemeinsame Priorisierungs-Workshops schaffen Alignment

Es gibt mehrere Methoden, um sich der Einordnung eines Features oder einer Story gezielt anzunähern. Ein Grundprinzip besteht jedoch zunächst darin, dass die Priorisierung nicht von einem Product Owner im stillen Kämmerlein vorgenommen werden sollte: Transparenz gegenüber Stakeholdern und die Zusammenarbeit mit ihnen ist entscheidend für ein übergreifendes Alignment.

Deshalb ist es sinnvoll, vor Releases oder Projekten gemeinsame Priorisierungs-Workshops durchzuführen, um alle Beteiligten auf dieselbe Seite zu ziehen und Sichtbarkeit zu schaffen. Für solche Priorisierungs-Workshops stehen mehrere Methoden zur Verfügung.

Zum Beispiel hilft der 6W-Ansatz, mithilfe der Antworten auf sechs Fragen jedes Backlog-Item und seinen Kundenutzen sachlich, umfassend und präzise zu beschreiben. Diese Form der Klarheit ist eine Voraussetzung für eine belastbare Priorisierung. Die Methode des User-Story-Mappings schafft im Team wiederum ein Verständnis, welche Reise ein Kunde oder User bei der Nutzung des Produkts unternimmt und welche Aktivitäten und Aufgaben er dabei ausführt.

Allerdings müssen alle Beteiligten verstehen, dass die MoSCoW-Prioritäten nicht in Stein gemeißelt sind. Die Could-Anforderung von heute ist womöglich schon morgen ein Must-Feature. Was im aktuellen Projekt als Won’t keine Berücksichtigung findet, wird in einem der nächsten Releases und angesichts eines ganz anderen Entwicklungsstadiums vielleicht ganz anders priorisiert. Umgekehrt ist es durchaus möglich, dass etwa aktuelle Should-Anforderungen zu einem späteren Zeitpunkt obsolet werden.

Prioritäten können sich mit der Zeit verschieben. Daher sind das Team und seine Stakeholder gut beraten, ihre Priorisierungen regelmäßig zu überprüfen und die Relevanz der Anforderungen aus dem Backlog neu zu bewerten.

Für jedermann verständliche Prioritäten – auch in Jira sichtbar

Der große Vorteil der MoSCoW-Methode besteht darin, dass die Prioritäten für alle Beteiligten klar verständlich sind. Sie geben auch fachfremden und weniger erfahrenen Beteiligten sofort Auskunft über die Bedeutung eines Features oder einer Story für ein Projekt oder Release.

Nun wäre es praktisch, wenn diese unmittelbare Sichtbarkeit nicht nur am physischen Board im Teamraum gegeben wäre. Letztlich wollen und müssen alle Beteiligten diese Informationen jederzeit erhalten können, ohne ihren Arbeitsplatz zu verlassen. Also ist es nötig, die Prioritäten in dem zentralen digitalen System abzubilden, mit dem die Teams ihre Projekte und Aufgaben verwalten – sprich: Jira.

Die gängige Methode dafür ist die Nutzung von Custom Fields, also benutzerdefinierten Feldern. Und mit der neuen App Awesome Custom Fields geht das besonders einfach und mit größtmöglicher Sichtbarkeit.

Sie versetzt Teams in die Lage, über Custom Fields die MoSCoW-Priorisierungen in ihre Vorgänge zu integrieren. (Diese lassen sich bei Bedarf jederzeit verändern.)

MoSCoW Priorisierung Jira

Im Priorisierungs-Workshop kann das Team für jeden Vorgang per Klick die Priorität nach dem MoSCoW-Prinzip definieren.

Die vergebene Priorität ist in jedem Ticket als visuelles Element präsent. Auch auf den Karten entsprechend konfigurierter Jira-Boards werden die Prioritäten der einzelnen Issues angezeigt.

MoSCoW Priorisierung Jira 2

Im Ticket wird die Priorität in Form eines visuellen Elements sichtbar gemacht.

MoSCoW Priorisierung Jira 3

Auf einem entsprechend konfigurierten Board sind die Prioritäten der einzelnen Issues ebenfalls zu sehen.

Awesome Custom Fields holt die wichtige und nützliche Jira-Funktion der benutzerdefinierten Felder aus der technischen Ecke heraus und macht sie besser zugänglich, verständlicher und einfacher zu nutzen. Dabei ist die Priorisierung nach MoSCoW nicht das einzige vordefinierte Custom Field, das die App "out of the box" mitbringt.

Mit WSJF-Werten, interaktiven Fortschrittsbalken, Multi-User-Auswahl, Sterne-Ranking, Statusampeln, Komplexitätsschätzungen in T-Shirt-Größen und anderen mehr bietet Awesome Custom Fields Felder für vielfältige gebräuchliche Anwendungsfälle in agilen Teams – und es werden ständig mehr.

Das folgende kurze Video gibt einen ersten Eindruck von den Möglichkeiten der App, und falls in deinen Teams ein erhöhter Bedarf an der Jira-Individualisierung mithilfe von Custom Fields besteht, lohnt sich definitiv ein zweiter, genauerer Blick.

Sie sehen gerade einen Platzhalterinhalt von Youtube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Awesome Custom Fields für Jira: Jetzt kostenfrei installieren!

Awesome Custom Fields ist kostenfrei auf dem Atlassian Marketplace erhältlich – und steht erst am Anfang. Das Entwicklungsteam arbeitet intensiv daran, weitere Anwendungsfälle umzusetzen und noch mehr Konfigurationsoptionen bereitzustellen. Im weiteren Jahresverlauf wird das Team mehrere große Features ausliefern, die die Arbeit mit benutzerdefinierten Feldern nochmals erleichtern und gleichzeitig flexibler machen, beispielsweise die Erstellung von Custom Fields auf Projektebene.

Hast du Fragen? Möchtest du mehr zum Status quo und zur Zukunft der App wissen? Wünschst du dir bestimmte Use Cases, die in der App noch nicht vorhanden oder geplant sind? Dann melde dich: Das Team freut sich darauf, mit dir ins Gespräch zu kommen!

Weiterführende Infos

In dieser Jira Admin-Schulung lernen IT- und Projektverantwortliche, wie sie ihr Jira-System technisch administrieren und Projekte sowie User verwalten.