{"id":25777,"date":"2025-12-19T16:12:57","date_gmt":"2025-12-19T15:12:57","guid":{"rendered":"https:\/\/www.pureconsultant.de\/de\/?p=25777"},"modified":"2025-12-19T16:13:07","modified_gmt":"2025-12-19T15:13:07","slug":"moscow-priorisierung-wont-have","status":"publish","type":"post","link":"https:\/\/www.pureconsultant.de\/de\/scrum\/moscow-priorisierung-wont-have\/","title":{"rendered":"MoSCoW Priorisierung – Won\u00b4t have"},"content":{"rendered":"
\n

MoSCoW Priorisierung – Won\u00b4t have – In einer Zeit, in der Projekte<\/a><\/strong> immer komplexer werden und Ressourcenknappheit den Alltag vieler Teams bestimmt, gewinnt die F\u00e4higkeit zur klaren Priorisierung einen enormen Stellenwert. Die MoSCoW-Methode<\/a><\/strong> hat sich als leistungsf\u00e4higes Instrument etabliert, um Anforderungen zielgerichtet nach ihrer Wichtigkeit zu ordnen. Doch w\u00e4hrend die Kategorien \u201eMust have\u201c und \u201eShould have\u201c in der Praxis h\u00e4ufig im Fokus stehen, bleibt gerade das \u201eWon\u2019t have\u201c oft unbeachtet oder wird sogar falsch interpretiert. Dabei verbirgt sich genau in dieser Kategorie ein zentrales Element f\u00fcr nachhaltigen Projekterfolg und Stakeholder<\/a><\/strong>-Zufriedenheit.<\/p>\n<\/div>

\n

Im Folgenden erfahren Sie nicht nur, wie die MoSCoW-Priorisierung insgesamt funktioniert, sondern insbesondere, welchen Stellenwert das \u201eWon\u2019t have\u201c besitzt, warum seine Anwendung oft schwerf\u00e4llt und wie Sie dieses Prinzip geschickt in den Projektalltag integrieren und davon profitieren k\u00f6nnen.<\/p>\n<\/div>

\n
\"MoSCoW
MoSCoW Priorisierung – Won\u00b4t have<\/figcaption><\/figure>\n<\/div>
\n
\n<\/div>
\n

Was ist die MoSCoW-Priorisierung? \u2013 Ein \u00dcberblick<\/h2>\n<\/div>
\n

Die MoSCoW-Methode ordnet Anforderungen in vier unterschiedliche Priorit\u00e4tsklassen ein, die durch die Anfangsbuchstaben des Namens repr\u00e4sentiert werden:<\/p>\n<\/div>

\n

Must have<\/h3>\n<\/div>
\n

Hierzu z\u00e4hlen Anforderungen, ohne die das Projektergebnis wertlos oder nicht funktionsf\u00e4hig w\u00e4re. Sie stellen die Mindestanforderungen dar, da sie absolut entscheidend f\u00fcr den Projekterfolg sind.<\/p>\n<\/div>

\n

Should have<\/h3>\n<\/div>
\n

Diese Anforderungen sind sehr wichtig, jedoch nicht unbedingt f\u00fcr einen erfolgreichen Abschluss im ersten Schritt notwendig. Oft k\u00f6nnen sie im Ausnahmefall verschoben werden, jedoch reduzieren sie den Gesamtwert des Projekts, wenn sie fehlen.<\/p>\n<\/div>

\n

Could have<\/h3>\n<\/div>
\n

In diese Kategorie fallen W\u00fcnsche, die den Nutzen des Projekts steigern, deren Fehlen aber keine gravierenden Auswirkungen hat. Nice-to-have-Features werden oft hier eingeordnet, da sie zus\u00e4tzlichen Mehrwert bieten, aber nicht kritisch sind.<\/p>\n<\/div>

\n

Won\u2019t have (for now)<\/h3>\n<\/div>
\n

Die vierte Kategorie \u2013 und der Hauptfokus dieses Artikels \u2013 kennzeichnet Anforderungen, die bewusst nicht im aktuellen Release oder Projektumfang enthalten sind<\/strong>. Sie k\u00f6nnen in der Zukunft an Bedeutung gewinnen, werden aber im Hier und Jetzt konsequent ausgeschlossen.<\/p>\n<\/div>

\n
\n<\/div>
\n

\u201eWon\u2019t have\u201c: Mehr als ein Ablageort f\u00fcr \u201esp\u00e4ter\u201c<\/h2>\n<\/div>
\n

Viele Interessenten stellen sich die Frage, ob die \u201eWon\u2019t have\u201c-Kategorie nicht letztlich einfach ein Aufschub f\u00fcr ungeliebte Aufgaben ist. W\u00e4hrend dies durchaus ein h\u00e4ufiger Irrglaube ist, liegt die eigentliche St\u00e4rke von \u201eWon\u2019t have\u201c darin, Fokus zu schaffen, klare Grenzen zu ziehen und Ressourcen zu sch\u00fctzen<\/strong>.<\/p>\n<\/div>

\n

Die wichtigsten Merkmale von \u201eWon\u2019t have\u201c-Anforderungen<\/h3>\n<\/div>
\n