Prioritäten von Anforderungen – Kategorie oder Reihenfolge?

Freitag, 6. November 2009 von  
unter Fachartikel Scrum

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 hat Zeit für später, auf was kann ggfs. ganz verzichtet werden.

Es gibt verschiedene Methoden und Verfahren, diese „Wichtigkeiten“ der Anforderungen zu bestimmen, auf die ich hier nicht näher eingehen möchte. Was mich hier aus aktuellem Anlass eher beschäftigt ist die Frage, wie diese Priorität anschließend festgehalt wird.
Aktuell sind mir dazu zwei Modelle geläufig: a) Einteilung in feste Kategorien und b) relative Priorität in Form einer Reihenfolge.

Betrachten wir beide Modelle mal kurz getrennt voneinander:

Kategorien: Zur Einteilung der Anforderungen wird eine Anzahl n Kategorien definiert. Besonders beliebt sind die Kategorien „Priorität 1“ bis „Priorität 5“. Wenn sich der Prozessverantwortliche noch besonders Mühe gibt, dann bekommen die Kategorien 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 ehrlich wäre es.

Mittels einer geeigneten Methode (z.B. Kano Modell) oder oft auch Bauchgefühl wird jeder Anforderung nun einer dieser Prioritätskategorien zugeordnet.

Der Vorteil dieses Modell ist, dass die meisten Methoden zur Priorisierung primär nur dieses Modell unterstützen (wie z.B. das Kano Modell) und dass neue Anforderung mit teilweise wenig Aufwand einfach in eine der Kategorien gesteckt werden können.
Nachteile ergeben sich aber oft in der Abarbeitung der Anforderung nach Priorität bzw. bei der Planung von Iteration in agilen Vorgehensmodellen. Dazu weiter unten aber mehr.

Reihenfolge: Die Anforderungen werden abhängig von ihrer Wichtigkeit/Dringlichkeit in eine lineare und eindeutige Reihenfolge gebracht. Hier weiß man genau genommen immer nur, die Anforderung A ist wichtiger als die Anforderung B und diese wiederum wichtiger als die Anforderung C. Man fängt mit zwei Anforderungen an und fügt dann weitere Anforderungen im Bubblesort-Verfahren (http://de.wikipedia.org/wiki/Bubblesort) in die Reihenfolge ein.

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 aber bei der Einsortierung nicht immer ganz unten anfangen; wenn ich weiß, meine neue Anforderung H ist wichtiger als die bereits einsortierte Anforderung D, dann ist sie auch automatisch wichtiger wie alle Anforderungen unterhalb von D und ich muss mich nur auf die Vergleiche oberhalb von D konzentrieren. Da kann es sich anbieten statt Bubblesort das Verfahren des binären Suchens (http://de.wikipedia.org/wiki/Binäres_Suchen) anzuwenden. Das ist doch mal spannend, mathematische Sortierverfahren bei der Priorisierung von Anforderungen einzusetzen. 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.

Vorteil der relativen Prioritäten (wie ich das Modell mit der Reihenfolge ab hier mal 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? Münze werfen oder die weiteren Begleitumstände beachten (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 behandeln wir mal in einem anderen Artikel).

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 oben 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 hilfreich.

Aber wie sieht es mit einer großen Anzahl an Anforderungen aus, wie sie schon 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 in unserem Beispiel, dass 30 Anforderungen nun P1 sind, 40 P2, weitere 20 P3 und die restlichen 10 verteilen sich gleichmäßig auf P4 und P5. Das ist irgendwie nicht unüblich, dass der überwiegende Teil der initialen Anforderungen ziemlich wichtig zu sein scheint.

Beim relativen Modell steigt der 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 (weiter unten sage ich da 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 (SP) 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 SPs haben, die Priorität vor allem anderen haben. Soweit war das Modell ja schon mal hilfreich. Im ersten Sprint unterbringen können wir aber nur 20 SP. 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 SPs des ersten Sprints werden auch umgesetzt, stehen für den zweiten Sprint 10 weitere SPs 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 von P2, und so weiter. Wir fangen uns hier also 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 hier nicht mehr, es ist jederzeit klar was als nächstes wichtig ist. Dafür haben wir aber vorher mehr Aufwand reinstecken müssen.

Und jetzt kommen wir zur Königsdisziplin, eine neue Anforderung, die wichtiger ist wie alles andere, sagen wir eine gesetzliche Vorgabe, die scheinbar über Nacht vom Himmel gefallen ist (neue gesetzliche Vorgaben werden vor allem in Konzernen ja gerne mal so lange 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 das wichtigste, aber meine neue Anforderung ist ja 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 hochpriore Kategorien 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 (in Bugzilla) hinzugefügt wird. Das kann dann z.B. so erklärungsbedürftige Ausprägungen wie blocker, critical, major, normal, minor, trivial und enhancement (diese gibt es so z.B. eben in Bugzilla aber auch anderen Tools) annehmen. Das ist aber nicht nur redundant, sondern kann 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 zu Chaos!

Bei der eindeutigen Reihenfolge des relativen Modells ohne Kategorien ist das Problem der neuen hochprioren Anforderung leicht zu lösen. Die neue Anforderung einfach ganz oben einsortieren, 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 Anforderungen werden) in die fünf Kategorien Basis-, Leistungs-, Begeisterungs-, Unerhebliches und Rückweisungsmerkmal ein.
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 zu fällen.

Fazit:
Kommen wir zur Antwort auf die sich nun stellende Frage, ob Kategorien in der Priorisierung von Anforderungen strikt abzulehnen sind. Nein, 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. Nur davon, dann bei diesen Kategorien stehen zu bleiben und auf dieser Basis dann z.B. die Sprint- oder Releaseplanung zu betreiben oder die Priorität von Anforderungen zu kommunizieren, rate ich dringend ab.

Kommentare

Einen Kommentar hinzufügen...

Sie müssen registriert und angemeldet sein um einen Kommentar zu schreiben.