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 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.
Definition[Bearbeiten | Quelltext bearbeiten]
Must[Bearbeiten | Quelltext bearbeiten]
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.
Should[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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[Bearbeiten | Quelltext bearbeiten]
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:
- Kein Stakeholder muss für die Aufnahme von Anforderungen „kämpfen“
- Bei Überlegungen zu zukünftigen Erforderlichkeiten werden auch aktuelle neu überdacht
- 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.
Kritikpunkte[Bearbeiten | Quelltext bearbeiten]
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:
- 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.
- Iterative Softwareentwicklung sorgt ebenfalls oft für eine Änderung der Prioritäten. Dadurch kommt es vor, dass Could-Anforderungen zu Should-Anforderungen werden.
Quellen[Bearbeiten | Quelltext bearbeiten]
- Coley Consulting - MoSCoW Priorisation (englisch)
Literatur[Bearbeiten | Quelltext bearbeiten]
- Iris Pinkster, Bob van de Burgt, Dennis Janssen, Erik van Veenendaal: Successful Test Management 2. Aufl. Springer Verlag, 2004, ISBN 978-3-540-44735-1 /ISBN 3-540-22822-5