MoSCoW-Priorisierung

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 Dynamic Systems Development Method.

MoSCoW ist ein Akronym und steht für:

• M - MUST (unbedingt erforderlich)
• S - SHOULD (sollte umgesetzt werden, wenn alle MUST-Anforderungen trotzdem erfüllt werden können)
• C - COULD (kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird)
• W - WON'T (wird diesmal nicht umgesetzt, aber für die Zukunft vorgemerkt)

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

Definition

MUST

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. Anforderung dieser Art werden in der Projekt-Timebox zusammengefasst. MUST ist ebenfalls ein Akronym – Minimal Usable SubseT – und steht für Minimalanforderung.

SHOULD

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

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

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 beim nächsten Release erneut berücksichtigt.

Eine gute WON'T-Liste bewirkt drei entscheidende Effekte:

1. Kein Benutzer muss für die Aufnahme von Anforderungen kämpfen
2. Bei Überlegungen über zukünftige Erforderlichkeiten werden auch aktuelle neu überdacht
3. Wenn die Designer die zukünftige Planung sehen, können Sie bei den 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. Er werden funktionale wie auch nichtfunktionale Anforderungen berücksichtigt.

Kritikpunkte

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 COULDs erbringen einen wichtigen Beitrag. Nur ist dieser nicht essentiell erfolgskritisch für das Projekt/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.

Quellen

• Conley Consulting - MoSCoW Priorisation (englisch)
• DSDM Atern - MoSCoW (englisch; kostenlose Registrierung erforderlich)

Literatur

• Iris Pinkster, Bob van de Burgt, Dennis Janssen, Erik van Veenendaal: Successful Test Management 2. Aufl. Springer Verlag, 2004, ISBN 3-540-22822-5