In Kürze: Das umgekehrte MoSCoW Rahmenwerk

Das umgekehrte MoSCoW Rahmenwerk kehrt dessen traditionelle Priorisierung um und konzentriert sich darauf, was ein Produktteam nicht entwickeln wird. Durch den bewussten Ausschluss von Funktionen können Teams die Entwicklung optimieren, eine schleichende Ausweitung des Projektumfangs vermeiden und sich auf das Wesentliche konzentrieren.

Dieses adaptierte Framework entspricht den agilen Prinzipien der Einfachheit und Effizienz, erfordert aber auch eine sorgfältige Umsetzung, um Starrheit, Fehlausrichtung oder Innovationshemmung zu vermeiden. Bei umsichtiger Anwendung ist das umgekehrte MoSCoW Framework ein leistungsstarkes Instrument zur Verwaltung des Produktumfangs und zur Förderung der strategischen Klarheit.

Lesen Sie weiter und erfahren Sie, wie Sie das umgekehrte MoSCoW-Framework für Ihr Team nutzen können.

---

January 27, 2025: The Advanced Product Backlog Management Course for Just $99!

Please note:

• The course includes membership in my former professional students‘ brand-new Hands-on Agile community.
• The course will only be available for sign-up until February 3, 2025!

---

Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 42.000 Abonnenten anschließen.

Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Beginnen wir mit MoSCoW

Das MoSCoW-Priorisierungs-Framework ist ein Tool, das Produktteams dabei unterstützt, ihre Bemühungen zu fokussieren, indem es die Arbeit in vier Ebenen kategorisiert:

1. Must-Have: Dies sind nicht verhandelbare Anforderungen, ohne die das Produkt nicht funktionieren oder seine Ziele nicht erreichen kann. Betrachten Sie sie als das Fundament Ihres Produkts. Beispielsweise ist ein funktionsfähiges Zahlungsgateway ein „Must-Have“ in einer E-Commerce-App.
2. Should-Have: Diese Funktionen bieten einen erheblichen Mehrwert, sind jedoch nicht geschäftskritisch. Wenn Zeit oder Ressourcen knapp sind, können diese Funktionen zurückgestellt werden, ohne dass das Produkt beeinträchtigt wird. Beispielsweise kann eine Filteroption auf einer Suchergebnisseite die Benutzerfreundlichkeit verbessern, ist jedoch für die Veröffentlichung der App nicht unbedingt erforderlich.
3. Could-Have: Dies sind „Nice-to-Haves“ – Funktionen, die nicht unbedingt erforderlich sind, aber die Benutzererfahrung verbessern würden, wenn sie implementiert würden. Hierunter könnten beispielsweise Animationen oder Hell-/Dunkel-Modi passen.
4. Won’t-Have: Hierbei handelt es sich um Funktionen, die für diesen Release-Zyklus ausdrücklich zurückgestellt wurden. Sie sind zwar noch dokumentiert, werden aber erst zu einem späteren Zeitpunkt in Betracht gezogen. Beispielsweise könnte die Integration einer Empfehlungsmaschine für Ihr MVP ein „Won’t-Have“ sein.

Um mehr über das ursprüngliche MoSCoW Rahmenwerk zu erfahren, empfehle ich den Wikipedia-Artikel oder das Kapitel 10 aus dem DSDM Agile Project Framework Handbuch.

MoSCoW-Vorteile

Das MoSCoW-Rahmenwerk bietet erhebliche Vorteile, darunter Klarheit und Fokussierung durch die Unterscheidung zwischen kritischen und optionalen Merkmalen, was Produktteams bei der effektiven Priorisierung unterstützt. Es unterstützt damit auch die Ausrichtung der Entwicklungsbemühungen an zeitlichen, budgetären und technischen Kapazitätsbeschränkungen. Seine Anpassungsfähigkeit ermöglicht es Teams, schnell auf Änderungen zu reagieren und bei Bedarf Elemente mit niedrigerer Priorität fallen zu lassen. Darüber hinaus fördert das Rahmenwerk die Abstimmung im Team, indem es ein gemeinsames Verständnis über funktionsübergreifende Gruppen hinweg schafft und sicherstellt, dass alle auf gemeinsame Ziele hinarbeiten.

MoSCoW-Mängel

Das MoSCoW-Rahmenwerk weist jedoch auch nennenswerte Mängel auf, darunter die Tendenz, die Priorisierung zu stark zu vereinfachen, indem Nuancen wie Abhängigkeiten von Merkmalen übersehen werden, bei denen ein „Must-have“ von einem „Could-have“ abhängen könnte.

Häufig fehlt eine quantitative Bewertung, stattdessen wird auf subjektive Einschätzungen von Interessengruppen oder Führungskräften zurückgegriffen, was zu einer Fehlausrichtung der Prioritäten führen kann, indem messbare Auswirkungen oder Anstrengungen vernachlässigt werden. Ohne eine solide Disziplin besteht die Gefahr, dass die Kategorie „Must-have“ aufgebläht wird, was die Teams überfordert und den Fokus verwässert. Darüber hinaus kann das Framework Output über Outcome stellen, was dazu führt, dass Teams der Bereitstellung von Funktionen Vorrang einräumen, ohne sicherzustellen, dass sie die gewünschten Kunden- oder Geschäftsergebnisse erzielen.

Bekannte MoSCoW-Anti-Muster sind:

1. Ohne strategischen Kontext angewendet: Wenn Prioritäten vergeben werden, ohne sie an eine klare Produktvision, Geschäftsergebnisse oder Nutzerbedürfnisse zu knüpfen, wird das Rahmenwerk willkürlich. Stellen Sie sicher, dass „Must-Haves“ direkt kritische Geschäfts- oder Kundenziele unterstützen.
2. Der „Must-Have-Creep“: Stakeholder ordnen oft zu viele Elemente der Kategorie „Must-Have“ zu. Dies untergräbt die Priorisierung und kann zu Überlastung führen. Widersetzen Sie sich, indem Sie fragen: Was passiert, wenn wir das nicht liefern?
3. Statische Prioritäten: MoSCoW funktioniert am besten in einem iterativen Kontext, kann aber scheitern, wenn Teams die Kategorien als starr behandeln. Prioritäten sollten regelmäßig überprüft werden, insbesondere während der Discovery-Phase oder wenn neue Einschränkungen auftreten.
4. Ignorieren von Abhängigkeiten: Eine Funktion mag zwar eine niedrige Priorität haben, könnte aber ein Element mit höherer Priorität blockieren. Daher sollten technische Abhängigkeiten bei der Priorisierung immer berücksichtigt werden.
5. Isolierte Entscheidungsfindung: Wenn Produktmanager Prioritäten festlegen, ohne die Entwickler zu konsultieren, kann dies zu technischen Unmöglichkeiten oder zur Unterschätzung der Komplexität von „Must-Haves“ führen.

MoSCoW auf den Kopf stellen – Lernen Sie das umgekehrte MoSCoW Rahmenwerk kennen

Lassen Sie uns ein kleines Gedankenexperiment durchführen: Erinnern Sie sich an das Prinzip des Agilen Manifests, dass “Simplicity–the art of maximizing the amount of work not done–is essential?” (Quelle.)

Warum also nicht MoSCoW auf den Kopf stellen?

Das umgekehrte MoSCoW Rahmenwerk kehrt das ursprüngliche Framework um und konzentriert sich in erster Linie auf das, was ein Produktteam nicht erstellen wird. Anstatt Funktionen oder Aufgaben zu priorisieren, die in ein Release aufgenommen werden sollen, betont dieser Ansatz bewusste Ausschlüsse und hilft Teams, Grenzen zu identifizieren und zu artikulieren. So ist es aufgebaut:

1. Won’t-Have (Absolut nicht): Funktionen oder Aufgaben, die für die absehbare Zukunft ausdrücklich ausgeschlossen sind. Dabei kann es sich um Ideen handeln, die nicht mit der Produktvision übereinstimmen, zu kostspielig oder zu komplex sind oder nicht genug Wert bieten. Die Debatte endet hier.
2. Could-Have (Aber unwahrscheinlich): Funktionen, die eines Tages in Betracht gezogen werden könnten, aber nicht praktisch oder wirkungsvoll genug sind, um bald priorisiert zu werden. Es handelt sich um Ergänzungen oder Verbesserungen mit geringem Wert und minimaler Dringlichkeit. Vielleicht kommen wir dazu, vielleicht auch nicht – keine Versprechungen!
3. Should-Have (Unter sehr spezifischen Bedingungen): Funktionen, die unter außergewöhnlichen Umständen erstellt werden könnten. Diese könnten Sonderfälle behandeln, Nischenzielgruppen bedienen oder von günstigen zukünftigen Bedingungen wie zusätzlichen Kapazitäten oder Nachfrage abhängen. Solange sich nichts Wesentliches ändert, sollten wir sie ignorieren.
4. Betrachtung verschoben (Future Consideration): Diese Funktionen oder Verbesserungen liegen ausdrücklich außerhalb des Rahmens. Das Team räumt ein, dass sie möglicherweise von gewisser Bedeutung sind, schließt sie aber vorerst bewusst aus, um sich auf die Kernziele zu konzentrieren.

Welche Vorteile bietet das umgekehrte MoSCoW Rahmenwerk?

Das Original auf den Kopf zu stellen hat mehrere Vorteile, da wir die Perspektive ändern und so neue Erkenntnisse gewinnen:

1. Entspricht dem Einfachheitsprinzip von Agile: Der umgekehrte MoSCoW-Ansatz verstärkt den Fokus auf agile Prinzipien durch die Maximierung der Menge an nicht ausgeführter Arbeit. Durch die Priorisierung von Ausschlüssen wird sichergestellt, dass das Team seine Energie auf die wertvollste und wirkungsvollste Arbeit verwendet.
2. Verbessert Fokus und Effizienz: Die Definition dessen, was nicht erstellt wird, reduziert Ablenkungen, schleichende Umfangsausweitungen und Diskussionen während der Entwicklung. Teams vermeiden es, Zeit mit unnützen Funktionen zu verschwenden, die zwar aufregend wirken, aber nur einen begrenzten Wert bieten.
3. Fördert strategische Zurückhaltung: Durch die ausdrückliche Angabe von Ausschlüssen trägt das umgekehrte Rahmenkonzept dazu bei, dass Ressourcen für die wichtigsten Probleme bereitgestellt werden. Es schützt auch vor zu großen Versprechungen oder der Verpflichtung zu Ideen, die keinen klaren Wert haben.
4. Erleichtert transparente Kommunikation: Stakeholder sind oft enttäuscht, wenn ihre Ideen nicht berücksichtigt werden. Die umgekehrte Struktur verdeutlicht, warum bestimmte Ideen ausgeschlossen werden, fördert die Abstimmung unter allen Beteiligten und reduziert Konflikte.
5. Ermöglicht langfristiges Denken: Teams können Funktionen oder Ideen in den Kategorien „Could-Have (aber unwahrscheinlich)“ oder „Betrachtung verschoben (Future Consideration)“ ablegen und so sicherstellen, dass sie dokumentiert bleiben, ohne von unmittelbaren Prioritäten abzulenken.
6. Verhindert kognitive Überlastung: Entwickler und Produktteams können sich ganz auf das Wesentliche konzentrieren, ohne sich in Debatten über „Extras“ zu verlieren. Es vereinfacht die Entscheidungsfindung, indem der Umfang im Voraus eingegrenzt wird.

Wenn wir beide Ansätze in einer vereinfachten Form vergleichen, würde dies wie folgt aussehen:

Aspect	Original MoSCoW	Inverted MoSCoW
Focus	What will be built	What won’t be built
Approach	Inclusion-oriented	Exclusion-oriented
Goal	Maximize delivery of prioritized features	Minimize waste and distractions
Stakeholder Role	Define priorities collaboratively	Understand and accept exclusions
Scope Creep Risk	Medium – „Should/Could“ items may creep into work	Low – Explicitly avoids unnecessary features
Alignment with Agile	Supports incremental delivery	Embraces simplicity and focus

Das Auf-den-Kopf-stellen von MoSCoW wendet agile Prinzipien an, indem unnötige Arbeit minimiert, der Fokus verbessert und die kognitive Überlastung reduziert wird. Es fördert eine transparente Kommunikation, ermutigt zu strategischer Zurückhaltung und dokumentiert Ideen für die zukünftige Berücksichtigung, um sicherzustellen, dass Produktteams sich auf das Wesentliche konzentrieren. Durch die Verankerung von Ausschlüssen in der Produktvision, die frühzeitige Einbindung von Interessengruppen und die regelmäßige Überprüfung von Entscheidungen können Teams eine schleichende Ausweitung des Projektumfangs vermeiden und Erwartungen effektiv verwalten, während sie gleichzeitig flexibel bleiben, um Anpassungen vorzunehmen.

Praktische Schritte zur Nutzung des umgekehrten MoSCoW Frameworks

Wenn Sie das umgekehrte MoSCoW Rahmenwerk zur Identifizierung wertvoller Arbeit verwenden möchten, sollten Sie die folgenden praktischen Schritte in Betracht ziehen, um Teammitglieder und Interessengruppen mit dem Ansatz vertraut zu machen und die Kommunikation zu optimieren:

1. Beginnen Sie mit Produktvision und -strategie: Verankern Sie Ausschlüsse in der Produktvision und -strategie. Wenn Sie beispielsweise eine leichtgewichtige, benutzerfreundliche App erstellen möchten, schließen Sie Funktionen, die unnötige Komplexität oder Aufblähung verursachen, bereits an dieser Stelle ausdrücklich aus.
2. Binden Sie die Stakeholder frühzeitig ein: Besprechen Sie Ausschlüsse im Voraus mit den Stakeholdern, um Erwartungen zu klären und zukünftige Konflikte zu reduzieren. Verwenden Sie das umgekehrte MoSCoW Rahmenwerk, um Entscheidungen zu verdeutlichen und zu vermeiden, dass Sie von den Stakeholdern als schwarzes Loch für Entscheidungen oder als einfache „Neinsager“ angesehen werden.
3. Erstellen Sie ein Backlog der Ausschlüsse – ein Anti-Produkt-Backlog: Führen Sie eine Liste der Features, die nicht umgesetzt werden. Dieses Anti-Produkt-Backlog dient als transparenter Leitfaden für zukünftige Diskussionen.
4. Regelmäßig überprüfen: Genauso wie sich Prioritäten verschieben können, können sich auch Ausschlüsse ändern. Überprüfen Sie Ihre Listen regelmäßig, um festzustellen, ob sich die Bedingungen geändert haben – Inspektion und Adaption sind entscheidend, um die Wertschöpfung innerhalb der gegebenen Einschränkungen durch die Organisation zu maximieren.
5. Dokumentieren Sie die Begründung: Dokumentieren Sie für jeden Ausschluss, warum er vorgenommen wurde, da Ausschlüsse dynamisch und kontextabhängig sind. Dieser Kontext hilft zu verhindern, dass dieselben Debatten erneut geführt werden, und stellt die Abstimmung zwischen Teams und Interessengruppen sicher. Was heute nicht machbar oder abgestimmt ist, könnte in Zukunft an Bedeutung gewinnen. Führen Sie ein Archiv der Ausschlüsse und bewerten Sie diese regelmäßig neu.

Darüber hinaus wäre es hilfreich, den Einsatz ergänzender Praktiken mit dem umgekehrten MoSCoW-Rahmenwerk in Betracht zu ziehen, zum Beispiel:

• Kombinieren Sie Frameworks für eine robuste Priorisierung: Kombinieren Sie das umgekehrte MoSCoW-Framework mit anderen Tools wie Impact-Effort-Matrizen, um Funktionen mit geringem Aufwand und hoher Wirkung zu identifizieren, die möglicherweise überdacht werden sollten, oder Opportunity Solution Trees, um zu visualisieren, wie Ausschlüsse mit übergreifenden Zielen übereinstimmen.
• Verwenden Sie Prototyping und Experimentieren: Überprüfen Sie die potenzielle Wirkung einer Idee durch einfache Prototypen oder Experimente, bevor Sie sie ausschließen. So stellen Sie sicher, dass vielversprechende Konzepte nicht vorschnell ausgeschlossen werden.

Rechnen Sie auch mit praktischen Herausforderungen, die Sie bei der Verwendung des invertierten MoSCoW Frameworks bewältigen müssen, zum Beispiel:

• Widerstand gegen Ausschlüsse: Stakeholder haben oft Schwierigkeiten zu akzeptieren, dass ihre Ideen ausgeschlossen werden. Um dem entgegenzuwirken, sollten Sie Ausschlüsse positiv kommunizieren – konzentrieren Sie sich auf den Wert der Priorisierung und die Vorteile der Bereitstellung eines schlanken, fokussierten Produkts für alle Beteiligten.
• Ausschlüsse als „endgültige Entscheidungen“: Ausschlüsse sind nicht dauerhaft. Sie sind Hilfsmittel, um Fokus und Umfang zu einem bestimmten Zeitpunkt zu verwalten. Ermutigen Sie die Teams, sie als flexibel und offen für Neubewertungen zu betrachten.
• Balance zwischen Fokus und Innovation: Während das umgekehrte MoSCoW Rahmenwerk Klarheit und Effizienz fördert, kann eine übermäßige Konzentration auf Ausschlüsse die kreative Erkundung behindern. Reservieren Sie Raum für strukturierte Product Discovery, um das Produkt wettbewerbsfähig zu halten.

Nachteile des umgekehrten MoSCoW-Rahmens

Der umgekehrte MoSCoW-Rahmen ist nützlich, um zu definieren, was ein Produktteam nicht entwickeln wird, und hilft, sich auf Einfachheit und Effizienz zu konzentrieren. Wie sein traditionelles Gegenstück ist es jedoch nicht ohne Mängel.

Eine große Herausforderung ist die Subjektivität bei der Entscheidung über Ausschlüsse. Die Beteiligten haben möglicherweise Schwierigkeiten, sich darauf zu einigen, was in die Kategorie „Won’t-Have“ gehört, was zu potenziellen Konflikten oder falschen Erwartungen führen kann. Ohne klare, objektive Kriterien für Ausschlüsse besteht die Gefahr, dass Entscheidungen willkürlich oder voreingenommen sind, was die strategischen Ziele untergräbt und den Zusammenhalt des Teams beeinträchtigt.

Ein weiterer Kritikpunkt ist die Tendenz des Frameworks, zu viel Einfachheit zu fördern, was Innovation oder langfristiges Denken ersticken kann. Während die Konzentration auf „nicht bauen“ mit den agilen Prinzipien der Einfachheit übereinstimmt, kann eine zu starke Priorisierung von Ausschlüssen den Umfang des Produkts zu sehr einschränken, sodass Teams nicht auf zukünftige Chancen oder sich ändernde Marktbedingungen vorbereitet sind. Es ist wichtig, Ausschlüsse mit Flexibilität in Einklang zu bringen, um sicherzustellen, dass Ideen mit strategischem Potenzial nicht vollständig verworfen, sondern für eine zukünftige Berücksichtigung angemessen kategorisiert werden.

Das Framework hat auch Schwierigkeiten, Abhängigkeiten zwischen ausgeschlossenen und eingeschlossenen Funktionen zu berücksichtigen. Der Ausschluss einer „Won’t-Have“-Funktion ohne Verständnis ihrer Rolle bei der Unterstützung anderer Arbeiten kann die Entwicklung unbeabsichtigt stören, zu Verzögerungen führen oder Nacharbeit erfordern. Ebenso kann die Nichtberücksichtigung von Aufwand oder Komplexität bei Ausschlüssen dazu führen, dass Gelegenheiten zur Bereitstellung von Funktionen mit geringem Aufwand und hoher Wirkung verpasst werden. Teams müssen Abhängigkeiten und Aufwände bewerten, um sicherzustellen, dass Ausschlüsse nicht versehentlich Fortschritt oder Innovation behindern.

Schließlich kann das umgekehrte MoSCoW-Rahmenwerk zu starr werden, insbesondere in agilen, iterativen Umgebungen, in denen sich Prioritäten schnell verschieben. Früh definierte Ausschlüsse stimmen möglicherweise nicht mehr mit den sich abzeichnenden Nutzerbedürfnissen oder Geschäftszielen überein, was zu Spannungen zwischen strategischer Absicht und praktischer Realität führt. Um dies zu mildern, müssen Teams Ausschlüsse als dynamisch behandeln und sie regelmäßig überprüfen und neu bewerten, um sicherzustellen, dass sie relevant und wirksam bleiben. Durch die Berücksichtigung dieser Kritikpunkte kann das umgekehrte MoSCoW-Rahmenwerk ein leistungsstarkes Instrument zur Steuerung von Fokus und Einfachheit bleiben, ohne dabei an Flexibilität oder strategischer Weitsicht einzubüßen.

Schlussfolgerung

Das umgekehrte MoSCoW Rahmenwerk ist ein leistungsstarkes Tool, das jedoch am effektivsten als Teil einer umfassenderen Priorisierungsstrategie ist. Durch die Betonung der Zusammenarbeit, die Fundierung von Entscheidungen auf Daten und die Wahrung von Flexibilität können Sie sicherstellen, dass Ausschlüsse den langfristigen Erfolg Ihres Produkts unterstützen – und nicht behindern. Iterieren Sie, kommunizieren Sie und stimmen Sie Entscheidungen auf strategische Ziele ab, und das Rahmenwerk wird Ihnen bei Ihren Produktentwicklungsbemühungen als wertvoller Verbündeter dienen.

Wie entscheidet Ihr Produktteam, was nicht gebaut werden soll? Bitte teilen Sie uns Ihre Ideen in den Kommentaren mit.

Das umgekehrte MoSCoW Rahmenwerk — Empfohlene Lektüre

Stefan Wolpers: The Scrum Anti-Patterns Guide (Affiliate advertisement at no cost to you.)

Alignment Tools: Creating Better Relationships Between Stakeholders and Teams

27 Product Backlog Anti-Patterns

Product Washing: Die Fallstricke einer oberflächlichen Product-Operating-Modell-Transformation

Agile Verhandlungen – Das Leben ist Verhandlungssache; warum sollte Scrum anders sein?

11 Proven Stakeholder Communication Tactics during an Agile Transition

Transformation to Agile Primitives: Rebuilding Agility from the Ground Up

Agile Failure Patterns in Organizations 2.0

Download the Scrum Anti-Patterns Guide for free

Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

✋ Nicht versäumen: Lernen Sie mehr über das umgekehrte MoSCoW Rahmenwerk im 20.000-köpfigen „Hands-on Agile“ Slack Team

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Bereiten Sie sich auf die Bewältigung des Product Operating Models vor, indem Sie den kostenlosen Scrum Anti-Patterns Guide lesen: