MoSCoW-Priorisierung

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Die MoSCoW-Priorisierung ist eine Methode, die im Bereich des Projektmanagements verwendet wird und es dem Projektmanager ermöglicht, die Umsetzung der Anforderungen anhand ihrer Wichtigkeit und ihrer Auswirkung zu priorisieren. Seinen Ursprung hat die MoSCoW-Priorisierung in der agilen Methode DSDM und kommt heute als Priorisierungstechnik für Projektabnahme- und Qualitätskriterien u. a. in PRINCE2 zum Einsatz.

MoSCoW ist ein Akronym und steht für:

  • M – Must have (unbedingt erforderlich)
  • S – Should have (sollte umgesetzt werden, wenn alle Must-Anforderungen trotzdem erfüllt werden können)
  • C – Could have (kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird)
  • W – Won’t have (wird diesmal nicht umgesetzt, ist aber für die Zukunft vorgemerkt).

Die kleingeschriebenen Buchstaben im Akronym sind nur zum Zweck der besseren Lesbarkeit vorhanden und haben keine weitere Funktion.

Must bezeichnet Anforderungen, die für das Projekt essentiell wichtig und nicht verhandelbar sind. Eine ganz oder teilweise ausbleibende Umsetzung würde zum Scheitern des Projekts führen. Anforderungen dieser Art werden in der Projekt-Timebox zusammengefasst. MUST ist ebenfalls ein Akronym – Minimal Usable SubseT – und steht für Minimalanforderung.

Obwohl Should-Anforderungen nicht erfolgskritisch für das Projekt sind, haben sie eine hohe Relevanz und sollten, soweit keine Beeinträchtigung von Must-Anforderungen auftritt, mit in der Projektumsetzung berücksichtigt werden. Should-Anforderungen können oft über verschiedene Wege umgesetzt werden.

Could-Anforderungen haben eine geringe Relevanz und werden oft als Nice to have bezeichnet. Sie werden erst berücksichtigt, wenn neben der prioritären Bearbeitung von Must- und Should-Anforderungen noch Kapazitäten vorhanden sind. Doch sollten Could-Anforderungen nicht pauschal ignoriert werden. Oft können ein paar einfach umzusetzende Could-Anforderungen einen nicht unerheblichen Mehrwert generieren, bei minimalen, zusätzlichen Entwicklungskosten.

Won’t-Anforderungen sind für das aktuelle Projekt bzw. den aktuellen Planungsabschnitt von geringster Priorität. Allerdings, und das ist einer der größten Vorteile von MoSCoW, zeigt die Klassifizierung als Won’t, dass die Anforderung fachlich und/oder technisch wichtig, aber nicht zeitlich kritisch ist. So klassifizierte Anforderungen geraten nicht in Vergessenheit und werden für die Planung des nächsten Release erneut priorisiert.

Eine gute Won’t-Liste bewirkt drei entscheidende Effekte:

  1. Kein Stakeholder muss für die Aufnahme von Anforderungen „kämpfen“
  2. Bei Überlegungen zu zukünftigen Erforderlichkeiten werden auch aktuelle neu überdacht
  3. Wenn die Designer die langfristige Planung sehen, können sie bei der aktuellen Umsetzung schon Vorkehrungen zur späteren Implementierung treffen

Die Vorteile der MoSCoW-Priorisierungsmethode liegen darin, dass im Gegensatz zu einer einfachen numeralen 1-bis-3-Priorisierung klar und nachvollziehbar definiert werden kann, welche Anforderungen zeitkritisch sind und den größten Business Impact haben. Es werden funktionale wie auch nichtfunktionale Anforderungen berücksichtigt.

Viele bezeichnen eine Nice-to-have-Anforderung (Could) auch als Erweiterung oder Feinheit und plädieren dafür, dass diese definitionsgemäß somit keine Anforderung mehr ist und auch nicht mehr als eine solche eingestuft werden sollte.

Dem entgegen stehen folgende Punkte:

  1. Da die Prioritäten von Anforderungen oftmals recht dynamisch variieren, ist es sinnvoll, auch die Could-Anforderungen weiterhin als richtige Anforderungen zu behandeln. Auch Could-Anforderungen erbringen einen wichtigen Beitrag. Nur ist dieser nicht erfolgskritisch für das Projekt bzw. Produkt.
  2. Iterative Softwareentwicklung sorgt ebenfalls oft für eine Änderung der Prioritäten. Dadurch kommt es vor, dass Could-Anforderungen zu Should-Anforderungen werden.