Ein typisches Problem in jedem Projekt (nicht nur in der Softwareentwicklung) ist die Frage der Prioritäten der Anforderungen. Was muss zuerst erledigt werden, was geht auch später, auf was kann ggfs. ganz verzichtet werden?
Es gibt verschiedene Methoden und Verfahren, diese Wichtigkeiten der Anforderungen zu bestimmen, auf die ich heute nicht näher eingehen möchte. Heute möchten wir uns jedoch mit der Frage beschäftigen, wie diese Prioritäten anschließend festgehalten werden.
Aktuell sind mir dazu zwei Modelle geläufig:
- Einteilung in feste Kategorien und
- relative Priorität in Form einer Reihenfolge
Betrachten wir im ersten Schritt beide Modelle mal getrennt voneinander:
Das Modell der Kategorien
Zur Einteilung der Anforderungen wird eine Anzahl von n Kategorien definiert. Besonders beliebt sind die Kategorien Priorität 1 bis Priorität 5. Wenn sich der Prozessverantwortliche noch besonders viel Mühe gibt, dann bekommen die Kategorien auch noch so sprechende Bezeichnungen/Beschreibung wie z.B. „must have“, „nice to have“ oder auch „sehr wichtig“, „wichtig“ oder „normal“.
Dass sich mal jemand getraut hätte eine Kategorie ganz offen als „wird wohl niemals gemacht werden“ zu deklarieren, habe ich leider noch nicht erlebt. Aber richtig ehrlich wäre es. Und wenn Sie doch zu einem dieser Mutigen gehören, mailen Sie mich an, ich werde Sie in späteren Artikel lobend erwähnen.
Mittels einer geeigneten Methode (z.B. dem Kano Modell) oder oft auch dem Bauchgefühl wird nun jede Anforderung einer dieser Kategorien zugeordnet.
Der Vorteil dieses Modell ist, dass die meisten Methoden zur Priorisierung primär nur dieses Modell unterstützen (wie z.B. das schon erwähnte Kano Modell) und dass neue Anforderung mit teilweise wenig Aufwand einfach in eine der Kategorien gesteckt werden können. Die Entscheidung, welcher Kategorie eine Anforderung zugeordnet wird, kann für jede Anforderung isoliert gefällt werden.
Idealerweise sind für alle Kategorien klare Kriterien definiert, anhand der die Entscheidungen über die Zuordnung gefällt werden. In vielen Organisationen ist dies aber oft nicht der Fall.
Nachteile ergeben sich oft in der Abarbeitung der Anforderung nach Priorität bzw. bei der Planung von Iteration in agilen Vorgehensmodellen, da dieses Modell keine geeignete Unterstützung bei zu knappen Kapazitäten zur Umsetzung der Anforderungen biete. Dazu aber gleich mehr.
Das Modell der Reihenfolge
Hier werden die Anforderungen abhängig von ihrer Wichtigkeit/Dringlichkeit in eine lineare und eindeutige Reihenfolge gebracht. Dadurch wissen alle Projektbeteiligte genau genommen immer nur, die Anforderung A ist wichtiger als die Anforderung B und diese wiederum wichtiger als die Anforderung C, ohne dass es dadurch schon eine qualitative Bewertung gibt. Es ist dadurch z.B. noch nicht klar, ob A es überhaupt wert ist, umgesetzt zu werden.
Eine größere Menge an Anforderungen in eine sortierte Reihenfolge zu bringen, scheint auf den ersten Blick eine komplexe Aufgabe zu sein. Das ist sie aber nicht mehr, wenn man die Aufgabe in kleinere Schritte runterbricht.
Ich nehme mir wahlfrei zwei erste Anforderung und vergleiche in diesem Schritt nur, welche von beiden mir wichtiger ist. Diese ordnen ich denn oberhalb der anderen Anforderung an. Dann nehme ich mir eine weitere Anforderung und fange oben an und vergleiche diese neue Anforderung mit der obersten Anforderung in meiner „Liste“. Ist die neue Anforderung wichtiger als die aktuell wichtigste Anforderung, dann ordne ich sie oben in der Liste an. Ist sie weniger wichtig, dann gehe ich zum nächsten Eintrag in der Liste und vergleiche die neue Anforderung mit diesem Eintrag, usw.
In der Programmierung kennen wir diese Verfahren als Bubblesort
Der Nachteil ist, dass der Initiale Aufbau der Reihenfolge etwas aufwändig scheint, da man die einzelnen Anforderungen bei der Frage nach ihrer Priorität nicht isoliert betrachten kann. Und auch bei der Aufnahme weiterer Anforderungen ist ein Vergleich mit den anderen Anforderungen notwendig.
Dabei muss man allerdings bei der Einsortierung nicht immer ganz oben oder unten anfangen; wenn ich z.B. weiß, dass meine neue Anforderung H wichtiger ist als die bereits einsortierte Anforderung D, dann ist sie auch automatisch wichtiger als alle Anforderungen unterhalb von D und ich muss mich nur auf die Vergleiche oberhalb von D konzentrieren.
Wenn mir gerade kein direkter Vergleich präsent ist, dann kann ich alternativ auch auf ein Verfahren zurückgreifen, dass in der Softwareentwicklung als Binäres Suchen bekannt ist.
Bei diesem Verfahren fange ich mit dem Vergleich in der Mitte meiner Liste an. Ich nehme mir also als ersten Vergleichskandidaten eine Anforderung aus der Mitte meiner Anforderungsliste und beantworte mir die Frage, ob meine neue Anforderung wichtiger ist, als diese Anforderung in der Mitte. Ist sie mir wichtiger, dann nehme ich mir als nächsten Vergleichskandidaten eine Anforderung, die in der Mitte zwischen meinem letzten Vergleichskandidaten und dem oberen Ende der Liste liegt und vergleiche wieder. Abhängig von diesem Vergleich suche ich mir jetzt wieder die Mitte im oberen oder unteren Viertel meiner Liste für den Vergleich aus und mache das solange weiter, bis ich genau zwischen zwei Anforderungen lande, die entsprechend etwas wichtiger bzw. unwichtiger als meine neue Anforderung sind.
Die Mathematiker jetzt aber bitte nicht alle melden und darauf hinweisen, dass es optimalere Algorithmen für die Sortierung gibt. Ich kann mir nur schwer vorstellen, dass tatsächlich ein Produktverantwortlicher oder Anforderungsmanager einen mathematischen Sortieralgorithmus verwenden wird, die Vergleiche dienen hier nur als anschauliche Beispiele.
Der Vorteil der relativen Prioritäten (wie ich das Modell mit der Reihenfolge ab hier nennen möchte) ist, dass ich hier nun eine eindeutige Reihenfolge habe, in der die Anforderungen umzusetzen sind.
Was ist, wenn ich zwischen zwei Anforderungen nicht entscheiden kann, welche von beiden wichtiger ist? Dafür kann es eigentlich nur einen von zwei Gründen geben:
- Der Unterschied in der Wichtigkeit ist so klein, dass ich deshalb keine eindeutige Entscheidung fällen kann oder es gibt sogar keinen. In diesem Fall treffen ich einfach eine Entscheidung. Durch Zufallsprinzip (Münzwurf) oder Bauchgefühl. Es spielt keine Rolle.
- Mir fehlen bei beiden Anforderungen die notwendigen Informationen, um die Entscheidung fällen zu können. Auch in diesem Fall kann ich einfach so eine Entscheidung fällen, es ist zu diesem Zeitpunkt quasi nicht wichtig, welche von beiden wichtiger ist, da beide Anforderungen in diesem Zustand nicht umsetzbar sind. Meine Aufgabe nach der eher zufälligen Entscheidung (ich muss mich entscheiden) ist jetzt, die notwendigen Informationen zu erlangen, damit ich eine qualifizierte Entscheidung fällen kann. Idealerweise sollten beide Anforderungen in diesem Zustand nicht zur sofortigen Umsetzung anstehen.
Ist klar, dass eine der beiden Anforderungen aufgrund äußerer Umstände erst später umsetzbar sein wird, dann kann sie auch direkt weiter nach unten wandern. Dies gehört aber zum Thema, wie überhaupt bestimmt werden kann, welche Anforderungen wichtiger sind wie andere. Das werden wir in späteren Artikeln behandeln.
Der direkte Vergleich
Werfen wir beide Modell nun mal in den Ring und betrachten wir ihre Stärken und Schwächen im direkten Vergleich. Bei einer kleinen überschaubaren Anzahl an Anforderungen machen sich beide Kandidaten recht gut. Die Vergabe der Prioritäten im auf Kategorien basierenden Ansatzes ist wie bereits besprochen ja eh recht trivial:
- Priorisierungsmethode der Wahl anwenden
- Ergebnis nehmen und auf Kategorien transformieren
- Fertig
Aber auch im relativen Modell ist der direkte Vergleich der Wichtigkeit der Anforderungen untereinander schnell erledigt. Und auch bei der Abarbeitung der Anforderungen bzw. der Einplanung zeigen sich beide Modelle in diesem Szenario noch recht hilfreich.
Wie sieht es denn bei einer größeren Anzahl an Anforderungen aus, wie sie in durchschnittlichen Projekten schnell erreicht ist? Wir unterstellen mal eine initiale Anzahl von 100 Anforderungen zum Projektstart. Und hier wird es langsam interessant.
Betrachten wir als erstes wieder den Aufwand für die Initiale Priorisierung der Anforderungen. Im auf Kategorien basierenden Modell nehmen wir mal die typische Aufteilung in fünf Kategorien an, die wir hier als P1 bis P5 bezeichnen wollen, wobei P1 für die wichtigsten Anforderungen stehen wird und P5 für die unwichtigsten.
Die Verteilung der 100 Anforderungen auf die fünf Kategorien ist erneut mit wenig Aufwand verbunden. Na gut, mit verhältnismäßig wenig Aufwand. Natürlich muss jede der 100 Anforderungen bewertet werden, das ist schon Arbeit. Als Ergebnis bestimmen wir jetzt in unserem Beispiel, dass 30 Anforderungen P1 sind, 40 P2, weitere 20 P3 und die restlichen 10 verteilen sich gleichmäßig auf P4 und P5.
Es scheint nicht unüblich zu sein, dass der überwiegende Teil der initialen Anforderungen als ziemlich wichtig bewertet wird. Zumindest begegnet mir das so laufend in Projekten.
Beim relativen Modell steigt der initiale Aufwand deutlich, denn hier müssen nun die 100 Anforderungen im Verhältnis zueinander nach Wichtigkeit sortiert werden. Das klingt aber schlimmer als es dann wirklich ist. Man fängt mit zwei Anforderungen an und fügt dann Anforderung für Anforderung hinzu. Und wie oben schon mal erklärt, muss nicht bei jeder Anforderung unten mit der Sortierung angefangen werden, sondern in der Regel kann direkt weiter oben in der Reihenfolge eingestiegen werden. Ich sage da gleich noch was zu.
Wie sieht es jetzt mit der Einplanung der Anforderungen aus? Auch hier treffen wir für unser Beispiel ein paar vereinfachte Annahmen. Wir definieren:
- dass wir mit Scrum arbeiten,
- dass alle Anforderungen mit einem Aufwand von einem Story Point geschätzt sind
- und dass wir in einen Sprint 20 Story Points unterbringen können
Wenn wir nun unseren ersten Sprint planen, dann stellen wir im Kategorienmodell fest, dass wir insgesamt 30 Story Points haben, die Priorität vor allem anderen haben. Soweit ist das Modell ja schon mal hilfreich.
Im ersten Sprint unterbringen können wir aber nur 20 Story Points. Welche sollen wir da nun nehmen? Hier fangen wir dann vermutlich an, diese 30 Anforderungen untereinander zu vergleichen, um innerhalb dieser Gruppe eine gewisse Sortierung zu erzielen. Das gleiche gilt dann für die nächsten Sprints.
Vorausgesetzt, die 20 geplanten Story Points des ersten Sprints werden auch umgesetzt, dann stehen für den zweiten Sprint 10 weitere Story Points der Priorität P1 an und 40 der Priorität P2, von denen aber nur 10 im Sprint Platz finden. Also wieder vergleichen und sortieren innerhalb der Kategorie P2, und so weiter.
Wir fangen uns also hier genau den Aufwand ein, den wir vorher bei der initialen Priorisierung vermeintlich gespart hatten.
Bei der bereits eindeutig sortierten Reihenfolge des relativen Modells haben wir diese Probleme bei der Einplanung in die Sprints nicht mehr. Es ist jederzeit klar was als nächstes am wichtigsten ist. Dafür haben wir aber auch vorher mehr Aufwand reinstecken müssen.
Und jetzt kommen wir zur Königsdisziplin: Eine neue Anforderung, die wichtiger ist wie alles andere Anforderungen, die wir bereits aufgenommen und bewertet hatten. Sagen wir, eine gesetzliche Vorgabe, die scheinbar über Nacht vom Himmel gefallen ist. Natürlich ist sie nicht wirklich überraschend vom Himmel gefallen, aber einige Organisationen sind erstaunlich gut darin, z.B. neue gesetzliche Vorgaben so lange zu ignoriert, bis sie dann auf den letzten Drücker doch plötzlich unvermeidbar scheinen.
Wie bilde ich das mit meinen Kategorien ab?
P1 ist ja schon die höchste und wichtigste Kategorie. Aber meine neue Anforderung ist sogar noch wichtiger als die 30 bereits als P1 eingestuften Anforderungen. Definiere ich jetzt adhoc eine neue Kategorie P0, die noch über P1 steht? Da dauert es garantiert nicht lange, bis auch diese neue Kategorie regelmäßig gefüllt wird, denn Kategorien mit Top-Priorität haben die Eigenschaft, Anforderungen anzuziehen.
Wir haben hier also ein nichttriviales Problem, dass in vielen Fällen damit gelöst wird, dass zusätzlich zur eigentlichen Kategorie noch ein weiteres Attribut wie z.B. Severity hinzugefügt wird. Das kann dann z.B. so erklärungsbedürftige Ausprägungen wie blocker, critical, major, normal, minor, trivial und/oder enhancement annehmen.
Und falls Sie jetzt vermuten, dass ich mir das nur ausgedacht habe, dann schauen Sie doch mal in Tools in ihrem Unternehmen nach, welche Attribute dort für die Bewertung von Anforderungen oder Tickets vorhanden sind und wie diese bei Ihnen verwendet werden.
Diese zusätzlichen Attribute sind aber nicht nur redundant, sondern können auch zu Inkonsistenzen führen. Was ist denn nun wichtiger, eine Anforderung mit P1/enhancement oder eine mit P3/blocker? Und wieso kann eine P3 Anforderung ein Blocker sein, bzw. wieso kann ein scheinbarer Blocker nur die Priorität P3 haben? Das führt eindeutig zu Chaos!
Bei der eindeutigen Reihenfolge des relativen Modells ohne Kategorien ist das Problem der neuen Anforderung, die wichtiger ist als alle bisherigen, dahingegen leicht zu lösen. Die neue Anforderung wird einfach ganz oben einsortiert. Problem gelöst.
Bis hierhin scheint das relative Modell also besser geeignet zu sein.
Jetzt hatte ich aber weiter oben ausgeführt, dass die meisten Methoden zur Priorisierung von Anforderungen eher das Denken in Kategorien unterstützen. Das jetzt schon mehrfach zitierte Kano Modell der Kundenzufriedenheit z.B. teilt Produktmerkmale, aus denen später Anforderungen werden, in fünf Kategorien ein:
- Basismerkmal,
- Leistungsmerkmal,
- Begeisterungsmerkmal,
- Unerhebliches
- und Rückweisungsmerkmal
Muss ich nun auf diese Methoden verzichten, wenn ich mit einem relativen Prioritätsmodell arbeiten möchte?
Natürlich nicht! Wenn ich eine eindeutige Reihenfolge meiner Anforderungen aufbauen möchte, dann muss ich die Wichtigkeit der einzelnen Anforderungen irgendwie begründen können. Warum ist denn die Anforderung A wichtiger als die Anforderung B? Da brauche ich für beide Anforderungen irgendwelche Anhaltspunkte dafür, weshalb sie wichtig oder auch nicht wichtig sind.
Und genau dafür sind viele Methoden der Priorisierung eine große Hilfe. Mit ihnen kann ich zumindest schon mal ein grobes Raster schaffen, dass mir bei der ersten Vorsortierung hilft. Und wenn die Anforderung A nach dem Kano Modell in die Kategorie Basismerkmal fällt und die Anforderung B in die Kategorie Leistungsmerkmal, dann weiß ich ganz automatisch, das A wichtiger ist als B. Und nur wenn die Anforderung C ebenfalls ein Basismerkmal zu sein scheint, muss ich mir im Vergleich von A und C mehr Informationen heranziehen, um hier eine eindeutige Entscheidung fällen zu können.
Fazit
Kommen wir zur Antwort auf die sich nun stellende Frage, ob Kategorien in der Priorisierung von Anforderungen strikt abzulehnen sind.
Ich sage nein, denn sie sind eine hilfreiche Zwischenstufe auf dem Weg zu einer sortieren Reihenfolge relativer Wichtigkeit. Und diese Zwischenstufe kann nicht nur viel Zeit sparen, sondern bei der Verwendung geeigneter Methoden die fundierte Basis für die Bewertung der relativen Wichtigkeiten liefern.
Ich allerdings davon ab, bei der Verwendung von Kategorien stehen zu bleiben und den Aufwand der Transformation in eine sortierte Liste zu scheuen, da z.B. in iterativen Verfahren wie Scrum die Kategorien meistens nicht dabei helfen zu identifizieren, was am sinnvollsten im nächsten Sprint umgesetzt werden soll.