Gruppierung

Ziel

Die Gruppierung verwandelt eine lange Liste von Anforderungen in eine kleine Zahl entscheidungsreifer Bänder. Das Problem, das sie löst, ist ein Inkrement mit festem Umfang, ein Release, eine Timebox oder ein festgelegtes Budget: Das Team muss rasch vereinbaren, was es enthalten soll und was zuerst gestrichen wird. Die Priorität hört auf, eine Meinung zu sein, die jede Person im Kopf trägt, und wird zu einer schriftlichen Kategorie, in der Sitzung vereinbart. An dem Tag, an dem eine Anforderung zurückgestellt wird, besteht ein Unterschied zwischen dem erneuten Aufrollen der Entscheidung und dem Hinweis «es ist ein Should, das haben wir gemeinsam entschieden».

Die Gruppierung ist einer der vier Ansätze zur Priorisierung, die das BABOK unterscheidet, neben der Rangfolge, dem Timeboxing und der Budgetierung und der Verhandlung. Dieselbe Familie versammelt auch kollaborative Ansätze wie das Dot-Voting und das Bullseye. Die Gruppierung steuert eine Aufteilung in Bänder bei, ohne Reihenfolge innerhalb eines Bandes, aus schriftlichen Definitionen, die alle gleich lesen.

Das Ergebnis liegt im Arbeitswerkzeug. Jede Anforderung trägt ein Prioritätsattribut, ihr Band, in der Regel ein Feld im Product Backlog oder im Anforderungsrepository. Das BABOK hält fest, dass viele Werkzeuge zur Anforderungsverwaltung erlauben, diese Kategorie als Attribut einer Anforderung zu führen. Das Artefakt ist eine Eigenschaft der Anforderungen, die bei jedem Planungszyklus überarbeitet wird.

Verwendung

Wann einzusetzen

• Lieferung mit festem Umfang oder Budget: eine vereinbarte Grundlage dafür geben, was zuerst wegfällt, wenn die Zeit knapp wird.
• Umfangreiche Anforderungsmenge: eine vollständige Reihung Stück für Stück kostet mehr Verhandlung, als die Entscheidung wert ist.
• Bedarf an gemeinsamem Wortschatz der Wichtigkeit: das «hoch, mittel, tief» ersetzen, das jede Partei anders liest.
• Anforderungen, die sich weiterentwickeln: Priorität zu einem Attribut machen, das bei jedem Planungszyklus überarbeitet wird.
• Mehrere Gruppen von Stakeholdern: rasch einen Umfangskonsens erreichen, ohne alles gegen alles zu reihen.

Wann nicht einzusetzen

• Zwei Elemente desselben Bandes müssen in fester Reihenfolge geliefert werden: die Gruppierung sagt nicht, welches zuerst kommt, die Rangfolge zum Sequenzieren nehmen.
• Harte Ressourcengrenze ohne Verhandlungsspielraum: von der Ressource ausgehen mit dem Timeboxing und der Budgetierung, die Bänder dienen erst danach als Zuteilungsregel.
• Grundsätzliche Uneinigkeit darüber, was zählt: das Kategorienschema ist nicht das Hindernis, die Verhandlung führen, bevor sortiert wird.

Beschreibung

Die vier Kategorien und die Regel, die sie zusammenhält

MoSCoW ordnet jede Anforderung genau einer von vier Kategorien zu, jede mit einer präzisen, vereinbarten Definition. Das Akronym liest sich aus seinen Anfangsbuchstaben, die beiden o dienen nur der Aussprache.

Das Must have ist nicht verhandelbar. Es bildet die minimal nutzbare Teilmenge. Der Test besteht aus einer einzigen Frage, «was geschieht, wenn dies nicht geliefert wird»: Ist die einzige ehrliche Antwort, die Lieferung abzusagen, ist es ein Must. Das Should have ist wichtig, ohne lebensnotwendig zu sein. Sein Fehlen schmerzt, ohne die Produktivsetzung zu blockieren, denn kurzfristig gibt es einen Behelf, einen manuellen Schritt oder einen Aufschub. Das Could have ist erwünscht, mit deutlich geringerer Wirkung, wenn es entfällt. Es bildet die Kontingenzreserve, das, was man als Erstes aufgibt, sobald ein Must oder ein Should gefährdet ist. Das Won't have this time ist ein datierter Aufschub: Die Anforderung ist für diesen Zeitraum als ausserhalb des Umfangs vereinbart und bleibt Kandidatin für den nächsten Zyklus. Diesen Aufschub festzuhalten, hält die Anforderung davon ab, wieder aufzutauchen und eine geschlossene Diskussion neu zu eröffnen.

In feste Behälter sortieren

Die Gruppierung teilt auf, sie reiht nicht innerhalb eines Bandes. Zwei Must sind gleichermassen Must, und MoSCoW sagt nicht, welches zuerst gebaut wird. Wenn die eigentliche Frage lautet «welches dieser beiden Must zuerst», typischerweise weil das eine technisch vom anderen abhängt, ist die Rangfolge gefragt: Sie erzeugt eine vollständige Reihenfolge, während die Gruppierung nur Bänder erzeugt. Die Behälter sind fest und im Voraus bekannt, die Anforderungen fallen hinein.

MoSCoW

Auf dieser Aufteilung ruht eine Aufwandsregel, die von DSDM und dem Agile Business Consortium stammt und im BABOK keine Entsprechung hat. Die Must sollten 60 % des gesamten geschätzten Aufwands des Inkrements nicht übersteigen, und die Could bilden eine Kontingenzreserve von rund 20 %. Jenseits von 60 % Aufwand in Must ist die Vorhersagbarkeit der Lieferung gefährdet, ausser in einer gut verstandenen Umgebung, mit einem eingespielten Team und geringem externem Risiko. Diese Proportion verwandelt eine Summe einzelner Einschätzungen in ein überprüfbares Budget: Verbrauchen die Must drei Viertel des Inkrements, lautet der Schluss, dass Elemente falsch eingestuft sind.

Die Sortierung durchführen

1. Die Banddefinitionen vor jeder Sortierung veröffentlichen
   Die vier von DSDM oder hauseigene Kategorien, falls MoSCoW nicht die Konvention ist, schriftlich und präzise.
2. Jede Anforderung genau einem Band zuweisen
   Mit den Stakeholdern, die zu Geschäftswert, Risiko und Dringlichkeit sprechen können.
3. Die Aufwandsbalance nach dem ersten Durchgang prüfen
   Den geschätzten Aufwand je Band summieren. Übersteigen die Must deutlich 60 %, sind Elemente überschätzt und verlangen eine erneute Prüfung.
4. Die Won't festhalten
   Sie für den nächsten Zyklus sichtbar lassen, wo sie als datierte, überprüfbare Entscheidungen wiederkehren.
5. Die Zuordnung im Projektverlauf erneut durchspielen
   Das BABOK hält fest, dass die Business-Analystin die Prioritäten überprüft, wenn Änderungen auftreten.

Was die Übung scheitern lässt

Die Must-Inflation ist das häufigste Versagen. Am Ende wird alles Must genannt, entweder weil die Kategorien zu lasch vereinbart wurden oder weil die Anforderung auf einer zu hohen Ebene formuliert war, um abgewogen zu werden. Das Mittel, aus der DSDM-Praxis gewonnen, heisst zerlegen, bevor eingestuft wird. Eine grobe Anforderung wie «den Kontostand einsehen» ist ein Must, aber ihre Variante der Mehrwährungsanzeige, einmal durch die funktionale Dekomposition isoliert, erweist sich oft als Should oder Could. Ein zu grosses Must verbirgt oft Could in seinem Inneren.

Das fehlende Won't ist das Gegenstück zur Must-Inflation. Teams stufen bereitwillig in Must, Should und Could ein, weisen aber nie ein Won't zu. Ausserhalb des Umfangs liegende Elemente bleiben dann in einem mehrdeutigen «vielleicht später», wo ein Won't sie zu einer festgehaltenen, überprüfbaren Entscheidung gemacht hätte. Eine MoSCoW-Liste ganz ohne Won't hat die schwierigen Entscheidungen fast immer umgangen.

Bänder ohne Entscheidungsregel sind die dritte Panne. Ein «hoch, mittel, tief» ohne ausgesprochenen Test, was etwas hoch macht, fällt auf das Kräfteverhältnis in der Sitzung zurück. Das BABOK seinerseits nennt unter den Grenzen der Priorisierung drei Klippen, die MoSCoW nicht allein aufhebt: Stakeholder, die den schwierigen Abwägungen ausweichen; ein Realisierungsteam, das die Implementierungsschwierigkeit überzeichnet, um die Priorisierung zu beeinflussen; das häufige Fehlen harter Kennzahlen, das die Übung subjektiv hält, solange keine Disziplin sie einrahmt. Diese Disziplin ist die schriftliche Definition der Bänder und die Prüfung der Aufwandsbalance.

KI-Überlegungen

Der erste Einsatz ist die Erstsortierung. Ein Sprachmodell, dem man den Anforderungstext übergibt, schlägt für jede eine Bandzuweisung vor, die ein Mensch bestätigt oder korrigiert. Bei einem Backlog von mehreren hundert Zeilen erspart diese Triage den mühsamsten Teil und belässt das Urteil dort, wo es zählt, bei den strittigen Fällen.

Der zweite Einsatz ist der lohnendste: das Aufspüren inkohärenter Einstufungen. Zwei nahezu identische Anforderungen, von denen die eine Must und die andere Should ist, eine Anforderung von offenkundig geringerem Wert als Must markiert, während stärkere Nachbarn Could sind, das Modell erkennt diese Widersprüche über Hunderte von Zeilen hinweg, wie es ein Raum nie tun wird. Es berechnet ebenso die Aufwandssumme je Band und meldet, wenn die Must die Schwelle von 60 % überschreiten.

Was die KI nicht tun darf, ergibt sich aus der Natur des Bandes. Der Geschäftswert einer Anforderung ist eine Stakeholder-Entscheidung, verankert in einem Kontext, den das Modell nicht hat: eine regulatorische Exponierung, eine politische Empfindlichkeit, eine gegenüber einem bestimmten Kunden eingegangene Verpflichtung. Ein Modell kann nicht der alleinige Urheber eines Must-, Should-, Could- oder Won't-Urteils sein, das anschliessend als vereinbart behandelt würde, denn der ganze Wert von MoSCoW ist die menschliche Übereinkunft hinter dem Etikett. Ein von der Maschine erzeugtes und ohne Sitzung übernommenes Band ist ein Etikett ohne Verpflichtung. Schliesslich trägt ein Backlog oft sensible strategische Informationen, eine nicht angekündigte Preisgestaltung, nicht offengelegte Funktionen, sodass seine Übergabe an ein externes Werkzeug eine Entscheidung der Datenverarbeitung ist.

Beispiele

Eine Krankenkasse der Westschweiz bereitet das nächste Release ihres Versichertenportals im Self-Service vor, ein Inkrement mit festem Budget von CHF 180'000 über zwölf Wochen.

Der Prämienrechner ist ein Could, der erste Kandidat für den Verzicht, falls ein Must ins Rutschen gerät, weil das Portal ohne ihn nutzbar bleibt. Der Chatbot steht in der Liste als Won't have this time, eine datierte Entscheidung, ihn aufzuschieben. Ihn festgehalten zu haben, verhindert, dass er in drei Wochen als neue Anfrage wieder auftaucht, die neu abzuwägen wäre. Zeigte die Schätzung dann, dass die beiden Must drei Viertel der zwölf Wochen verbrauchen, wäre dies das Signal, ihre Aufteilung neu zu öffnen, statt an den Should zu knapsen, gemäss der 60 %-Regel.

Visualisierungen

Die Liste der Bänder besteht aus Zeilen und Spalten. In HTML geschrieben, lässt sich das Bandattribut sortieren, filtern, per Formel zählen und ins Backlog-Werkzeug zurückkopieren, was ein Bild einer Tabelle verwehrt. Das Band trägt eine auf dem Artefakt lesbare schriftliche Definition, das Won't erscheint gleichrangig zu den drei anderen Bändern, und jede Anforderung belegt genau eine Zeile in einem einzigen Band.

Der Sortiermechanismus hingegen passt nicht in eine Tabelle, weil er auf Positionen und Proportionen beruht. Er wird gezeichnet: eine eingehende Menge von Anforderungen, vier feste, beschriftete Behälter, die sie aufnehmen, und das durch die Grösse der Behälter sichtbar gemachte Aufwandsbudget: höchstens 60 % für die Must, eine Reserve von rund 20 % für die Could. Diese Ansicht hebt die Gruppierung auf einen Blick von ihren Nachbarn ab, während die Rangfolge eine einzige geordnete Reihe aufstellen und das Timeboxing von einem Behälter fester Grösse ausgehen würde.

Kosten

Werkzeuge

Jedes Werkzeug zur Anforderungsverwaltung oder zum Backlog, das ein benutzerdefiniertes Prioritätsfeld oder -etikett zulässt, ist geeignet, von Jira über Azure DevOps bis zu einem Anforderungskatalog oder einer einfachen geteilten Tabellenkalkulation. Es gibt keinen Grund, eines zu empfehlen: Wesentlich ist, dass das Band ein Attribut der Anforderung selbst ist, das mit ihr überarbeitet wird.

Die Tabellenkalkulation verdient eine eigene Erwähnung. Die Aufwandsbalance wird dort zur Formel: eine Spalte des geschätzten Aufwands, eine Summe je Band, eine Zelle, die rot wird, sobald der Anteil der Must 60 % übersteigt. Die Prüfung, die die Technik bei jedem Durchgang verlangt, geschieht dann von selbst, im Augenblick der Eingabe der Sortierung. Dieselben Formeln spüren die verdächtigen Einstufungen auf und zählen, wie viele Elemente jedes Band hält. Ein Backlog-Werkzeug legt das Band dorthin, wo das Team ohnehin liest, und versioniert es, was dem banalsten Wartungsversagen begegnet, einer nur einmal gesetzten und nie wieder aufgegriffenen Priorität. Das zu vermeidende Werkzeug ist die Folie: Eine MoSCoW-Liste in einer Präsentation ist die Fotografie einer Abwägung, sie sortiert nicht, zählt nicht neu und veraltet bei der ersten Neuschätzung.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.33 Prioritization: die Gruppierung als einer der vier Priorisierungsansätze, das generische Beispiel «hoch, mittel, tief», die Führung der Prioritätskategorie als Attribut einer Anforderung, die erneute Prüfung der Prioritäten bei Änderungen und die anerkannten Grenzen der Priorisierung, ausgewichene Abwägungen, überzeichnete Implementierungsschwierigkeit und Knappheit harter Kennzahlen. Beschreibend zitiert: Das BABOK definiert weder die MoSCoW-Kategorien noch die Aufwandsregel.
• Agile Business Consortium, MoSCoW Prioritisation, DSDM Project Framework: die Definitionen der vier Kategorien, Must have als minimal nutzbare Teilmenge, Should have, Could have als Kontingenz und Won't have this time als datierter Aufschub, sowie die Aufwandsbalance: eine Obergrenze von 60 % für die Must und eine Reserve von rund 20 % für die Could. Dies ist die Quelle sämtlicher operativer Regeln von MoSCoW.
• Dai Clegg und Richard Barker, Case Method Fast-Track: A RAD Approach, Addison-Wesley / Oracle, 1994: der Ursprung von MoSCoW, von Dai Clegg geprägt und dann vom DSDM-Konsortium übernommen. Zitiert für diese einzige historische Tatsache, die heutigen operativen Regeln gehören zur aktuellen Publikation des Agile Business Consortium.