Moskau, Moskau wirf die Gläser an die Wand, Rußland ist ein schönes Land Ho ho ho ho ho, hey… Dieser Schlager von Dschinghis Khan erklang neulich als instrumentaler Tusch in einer Karnevalssendung und hat mich auf die Idee zum heutigen Blog gebracht. Ja, manchmal bleibt man beim Zappen im närrischen Treiben hängen und staunt, wie Teile der Republik dem Frohsinn frönen, während hier in Berlin ganz preußisch ernst weitermaloocht wird. Aber heute soll es ja nicht um den Karneval gehen, sondern darum, wie Sie Ihre Anforderungen priorisieren und in eine sinnvolle Reihenfolge bringen. Da kommt dann doch wieder Moskau ins Spiel.
MoSCoW Technik
Das MoSCoW Prinzip für die Priorisierung von Anforderungen wurde von Dai Clegg 1994 entwickelt. Er war damals bei Oracle in Großbritannien tätig und einer der Vertreter der Dynamic Systems Development Method (DSDM). DSDM ist eine agile Methode, die den gesamten Lebenszyklus eines Projektes beschreibt und heute noch vom Agile Business Consortium[1] vertrieben wird. Und was hat diese Methode mit der russischen Hauptstadt zu tun? Rein gar nichts.
Lediglich die Anfangsbuchstaben der Verben Must, Should, Could und Won’t, die zur Einschätzung der Notwendigkeit von Anforderungen benutzt werden, waren für die Namensgebung ausschlaggebend. Die os sind einfach nur Füllmasse, damit die Abkürzung gut klingt, sich leicht aussprechen lässt und in Erinnerung bleibt.
Eine Anforderung ist laut Definition eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, Systems oder Prozesses. Nicht alle Anforderungen sind gleich wichtig. Deshalb muss man spätestens bei der Projektplanung eine Priorisierung vornehmen. Um zu entscheiden, welche Anforderungen zuerst oder überhaupt umgesetzt werden müssen, kann man sie – gemeinsam mit den Stakeholdern – einteilen in:
M – Muss es haben
S – Sollte es haben, wenn möglich
C – Könnte es haben, wenn es nicht anderen Anforderungen in die Quere kommt
W – Wird es diesmal nicht haben, wäre aber wünschenswert in der Zukunft
Innerhalb der vier Gruppen ist keine Sortierung vorgesehen, d.h. alle Anforderungen innerhalb einer Gruppe sind zunächst einmal gleichrangig. Nach der Einteilung in M, S, C, W sollten die Anforderungen mit anderen Planungsaspekten (Umfang, Qualität, Zeit und Ressourcen) abgeglichen und eventuell weiter sortiert werden. Die M-Anforderungen sind absolut nicht verhandelbar. Sie müssen außerdem aufeinander abgestimmt sein, können also nicht im Widerspruch zueinander stehen. Die S- und C-Anforderungen sind sozusagen „nice to have“, die W-Anforderungen werden nicht implementiert, sollten aber unbedingt aufbewahrt werden, weil Sie vielleicht bei einem späteren Release von Bedeutung sein könnten. MoSCoW eignet sich vor allem dann, wenn die Anforderungen noch gar nicht eingeplant und sortiert sind.
100 Dollar oder 100 Punkte Technik
Einer der Erfinder dieser Technik ist ebenfalls kein Unbekannter in der agilen Szene: Dean Leffingwell, Mitbegründer des Scaled Agile Frameworks (SAFe). Der andere Erfinder Don Widrig hat sich mittlerweile in die Berge Colorados zurückgezogen, beobachtet dort Elche und hilft hin und wieder ehrenamtlich bei Computerproblemen seiner Mitbürger.
Bei der 100 Dollar Methode stimmen die Stakeholder demokratisch darüber ab, welche Anforderungen am wichtigsten sind. Die Teilnehmer bekommen jeweils symbolische 100 Dollar, die sie für die Realisierung der verschiedenen Anforderungen ausgeben können. Wie sie die 100 Dollar aufteilen, bleibt ihnen selbst überlassen. Am Ende wird gezählt, wie viel für jede Anforderung ausgegeben wurde und eine Rangliste erstellt. Diese Methode funktioniert gut, wenn es eine übersichtliche Anzahl an Anforderungen zu priorisieren gibt und viele Stakeholder befragt werden müssen. Von dieser Sorte „kumulativer Abstimmungstechniken“ gibt es noch weitere, z.B. das Dot-Voting, bei dem statt symbolischem Geld Punkte vergeben werden.
Paarweiser Vergleich mit Bubble Sort
Die Blasensortierung (so könnte man das übersetzen) ist eine Technik, die den sogenannten Algorithmus Bubble Sort für die Anforderungspriorisierung verwendet. Joachim Karlsson und Kevin Ryan kamen 1997 erstmals auf diese Idee. Im Prinzip werden dabei Anforderungen in Listen verglichen. Und zwar immer paarweise, nacheinander. Also die erste Anforderung in der Liste mit der zweiten. Ist die zweite Anforderung wichtiger als die erste, müssen die beiden ihren Listenplatz tauschen. Danach wird die zweite Anforderung in der Liste mit der dritten verglichen und so weiter. So wird die Liste nach Wichtigkeit sortiert. Die Anforderung mit der geringsten Bedeutung sollte am Ende den letzten Listenplatz haben. Die wichtigsten Anforderungen steigen also wie Luftblasen an den Anfang der Liste auf.
Innerhalb der Liste bewegen sich die Anforderungen mit unterschiedlichen Geschwindigkeiten nach oben oder unten. Der Bubble Sort Algorithmus ist vergleichsweise langsam. Eine Anforderung, die sich zum Anfang der Liste bewegen muss, kann sich nicht schneller als einen Schritt pro Durchgang bewegen. Wenn sich also zu Beginn der Sortierung die unwichtigste Anforderung am Ende der Liste befindet, braucht sie n-1 (n= die Anzahl der Listenelemente) Durchläufe, um dorthin zu kommen. Im schlechtesten Fall dauert es aber O(n²) Vergleiche, bis ein Element an der richtigen Stelle einsortiert ist[2]. Wegen dieser unterschiedlichen Geschwindigkeiten der Elemente gibt es bei dieser Technik Hasen und Schildkröten. Die Hasen wandern schnell, die Schildkröten langsam.
Mögliche Wege für Elemente in einer Bubble Sort Sortierung ©CC0
Diese Sortiertechnik braucht einige Zeit und ist daher nur für eine überschaubare Anzahl von Anforderungen geeignet. Wenn Sie noch einmal genauer anschauen wollen, wie der Bubble Sort Algorithmus funktioniert, empfehle ich Ihnen dieses Erklärvideo oder auch dieses Video, das den paarweisen Vergleich mit Legosteinen zeigt.
Ihre Top Ten
Es gibt natürlich noch jede Menge mehr Priorisierungstechniken. Der analytische Hierarchieprozess (AHP), der minimale Spannbaum oder binäre Entscheidungsbäume liefern laut Forschung zum Teil noch bessere Ergebnisse, sind aber auch komplexer in der Anwendung. Uns würde interessieren, wie Sie Ihre Anforderungen priorisieren? Wie kommen Sie im Team auf einen gemeinsamen Nenner? Oder haben Sie Tipps, die Sie gerne teilen möchten? Nur zu, hinterlassen Sie uns einfach einen Kommentar.
[1] Das Landau-Symbol O(n) steht als Symbol für eine Größe, deren Ordnung in Bezug auf n die Ordnung von n nicht überschreitet.
[2] https://www.agilebusiness.org/