Priorisieren mit MuSCoW

Es gibt viele Arten Aufgaben zu priorisieren. Eine davon möchte ich in diesem Beitrag einmal genauer betrachten. Dabei handelt es sich um die sogenannte MuSCoW Priorität. Die Abkürzung setzt sich aus must have, should have, could have, won’t have zusammen und lässt schon erkennen, was mit einzelnen Prioritäten gemeint ist.

Diese Priorisierung enthält einige Vorteile und Eigenarten auf die ich in dem Beitrag eingehe. Alle die bspw. LOP Listen bearbeiten oder einen Backlog in Scrum betreiben, finden hier wertvolle Tipps.

Ich kenne viele unterschiedliche Möglichkeiten ganz allgemeine Dinge wie Aufgaben, Arbeitspunkte, Backlogeinträge etc. zu priorisieren. Dabei stelle ich generell immer fest, dass nach kurzer Zeit Prioritäten nicht mehr ausreichen. Der eine ist der Meinung er braucht aber unbedingt 10 Abstufungen um Aufgaben zu priorisieren. Ein anderer weiß eigentlich gar nicht, was mit seinen 4 Prioritäten A, B, C, D denn genau gemeint ist und priorisiert alles erstmal generell auf A oder B und macht sich später erst Gedanken, warum kein wirklicher Fortschritt zu erkennen ist.

In den  meisten Fällen ist das unnötig. Ich brauche nur wenig Prioritäten, die auch aussagekräftig sein müssen. Dazu finde ich dann ganz oft in Firmen sogenannte Mapping Sheets, die auf der einen Seite die Priorität beschreiben auf der anderen was diese bedeutet. In meinen Augen ist es deutlich besser direkt aus einer Priorität ablesen zu können, was denn genau gemeint ist. Diskussionen über den Sinn und den Inhalt der Prioritäten werden so auch vermieden.

Die MuSCoW Priorität im Detail

Auch wenn die Prioritäten an sich selber erklärend sind, will ich die einzelnen Begriffe noch mal erläutern.

• Must have
  Hier gibt es keinen Zweifel – diese Priorität hat Vorrang vor allem und muss auf jeden Fall umgesetzt werden. Dadurch beschreibt die Priorität alle Themen die bspw. keine Verschiebung erlauben, als erstes umgesetzt werden müssen oder aber auch sehr risikoreich sein können.
• Should have
  Alle Themen die man haben sollte, aber vielleicht kein Risiko wie bei Must have besitzen aber wichtig für die Umsetzung sind.
• Could have
  Das sind alle Themen die man gerne im Produkt hätte, die schön sind wenn man sie umgesetzt bekommet, aber trotzdem nicht so wichtig sind wie die Should haves. Die letzte Priorität, die im aktuellen Release umgesetzt wird.
• Won’t have
  Ganz klar: Dieses wird nicht mehr umgestetzt. Es kann zum Beispiel im nächsten Release umgesetzt werden.

Das folgende Bild gibt einen Überblick.

MuSCoW Priorität im Einsatz

Nehmen wir an, Sie haben einen Scrum Backlog. Dort haben Sie als Product Owner auch priorisierte Einträge. Wenn jetzt Releases oder auch andere Sprint Backlogs erstellt werden, kann man an der Stelle sehr gut die MuSCoW Priorität nutzen.

Was passiert aber ganz oft? Die Termine ändert sich, nun müssen doch plötzlich Anforderungen geändert oder entfernt werden. Dann hat man die Möglichkeit bspw. die Could Have Einträge in dem Release nicht mehr zu betrachten

Sollte man am Ende noch “Luft” über haben, so steht es natürlich auch frei hier noch einige Won’t Haves mit in das aktuelle Release zu integrieren.

Natürlich werden jetzt einige sagen, und was soll der Unterschied zu einer 1,2,3,4 oder A,B,C,D Priorisierung sein? Es ist einfach die Benamung und die Semantik die gleich mitgeliefert wird. Aus meiner Sicht, sollte man sich den Einsatz ruhig  mal überlegen bzw. ausprobieren.

Haben Sie damit Erfahrungen gemacht? Schreiben Sie doch einen Kommentar!

The do’s and don’ts

Weitere Informationen zu MuSCoW und Agile

Teilen und Kommunizieren